GNU bug report logs - #14325
24.3; cc-mode does not initialize correctly w/ -batch

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: gnu-emacs-bug <at> moderators.isc.org
Subject: bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
Date: Wed, 1 May 2013 17:23:46 +0000 (UTC)

Achim Gratz <Stromeko <at> nexgo.de> wrote:
> 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.

OK.  Could you possibly give the exact sequence of Font Lock and CC Mode
calls which lead to the error?

> 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?

The variable is (or should be) initialised by font-lock-mode-hook calling
c-after-font-lock-init.  This should happen when font-lock-mode is called.
The question is why the switching on of Font Lock Mode here fails to do
this.

>> 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.

OK.

>> 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.

I'd like to track this down, too.

> Regards,
> Achim.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.