[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
From: |
Achim Gratz |
Subject: |
bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch |
Date: |
Wed, 01 May 2013 18:26:25 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Alan Mackenzie writes:
> Yes, the c-after-font-lock-init call will initialise everything properly,
> though it's more a workaround than a solution.
So what would be the solution, then?
> Font Lock Mode is a minor mode, and part of its initialisation is calling
> font-lock-mode-hook. (font-lock-mode-hook is here c-after-font-lock-init.)
> If you run font-lock-fontify-buffer (etc.) without fully initialising Font
> Lock Mode, you're liable to run into bugs. If that were all there were
> to it, I'd have nothing more to say, but sadly it's not so simple.
Well, Org requires font-lock, it switches font-lock off and on when it
changes font-lock settings and it uses it for fontification with
whatever major mode the content wants to have. If there is a code-path
that enters cc-mode in uninitialized state, then shouldn't cc-mode check
for nil instead of crashing Emacs by blindly assuming it can funcall the
contents of that variable?
> Font Lock Mode is, by default disabled in batch mode. If you enable it,
> this also enables jit-lock-mode (which is surely wrong), which prevents
> any fontification actually taking place, since the buffer is never
> displayed on the screen to trigger the fontification.
Since Org can use the results of the fontification, some of it must
happen anyway? Besides, even if I stop jit-lock-mode from being
used (by adding it to font-lock-inhibit-thing-lock), cc-mode still
throws an error.
> I think the following sequence of commands would fontify the buffer
> properly in batch mode:
> (c-mode)
> (setq font-lock-support-mode nil) ; disable jit-lock-mode
> (font-lock-mode 1)
I've tried to put these (without switching to c-mode since selecting the
mode is done elsewhere) into various places and still get the same error
from cc-mode.
> However, you'll probably prefer to carry on with using Font Lock Mode
> uninitialised. ;-) I think Glenn's patch achieves this painlessly.
I'd prefer if fontlock-fontify-* would work in batch mode without
workarounds. I'll have no problem sticking (when noninteractive ...)
into the intialization or Org itself if that's the ticket. I still
don't have a clue where that should be done.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch, Alan Mackenzie, 2013/05/06