* bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
2013-04-30 17:45 ` bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch Achim Gratz
@ 2013-05-01 0:51 ` Glenn Morris
2013-05-01 3:37 ` Glenn Morris
2013-05-01 6:51 ` Achim Gratz
2013-05-01 12:53 ` Alan Mackenzie
` (6 subsequent siblings)
7 siblings, 2 replies; 15+ messages in thread
From: Glenn Morris @ 2013-05-01 0:51 UTC (permalink / raw)
To: Achim Gratz; +Cc: 14325
Minimal example:
./src/emacs -Q -batch --eval \
'(progn (find-file "./src/emacs.c") (font-lock-fontify-buffer))'
Ie, a use of font-lock that does not first call font-lock-mode-hook.
This was already fixed once:
http://lists.gnu.org/archive/html/emacs-diffs/2012-02/msg00114.html
but reverted:
http://lists.gnu.org/archive/html/emacs-diffs/2012-02/msg00348.html
There was some kerfluffle about it:
http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00380.html
To me, c-standard-font-lock-fontify-region-function seems pointless in
Emacs, where font-lock is preloaded since 22.1.
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
2013-05-01 0:51 ` Glenn Morris
@ 2013-05-01 3:37 ` Glenn Morris
2013-05-01 6:51 ` Achim Gratz
1 sibling, 0 replies; 15+ messages in thread
From: Glenn Morris @ 2013-05-01 3:37 UTC (permalink / raw)
To: Achim Gratz; +Cc: 14325
Glenn Morris wrote:
> To me, c-standard-font-lock-fontify-region-function seems pointless in
> Emacs, where font-lock is preloaded since 22.1.
Even it is wasn't preloaded, I still don't see anything wrong with the
following. cc-mode only changes the buffer-local value.
*** lisp/progmodes/cc-mode.el 2013-04-15 16:10:24 +0000
--- lisp/progmodes/cc-mode.el 2013-05-01 03:34:59 +0000
***************
*** 1160,1168 ****
;; `c-set-fl-decl-start' for the detailed functionality.
(cons (c-set-fl-decl-start beg) end))
- (defvar c-standard-font-lock-fontify-region-function nil
- "Standard value of `font-lock-fontify-region-function'")
-
(defun c-font-lock-fontify-region (beg end &optional verbose)
;; Effectively advice around `font-lock-fontify-region' which extends the
;; region (BEG END), for example, to avoid context fontification chopping
--- 1160,1165 ----
***************
*** 1187,1193 ****
(setq new-region (funcall fn new-beg new-end))
(setq new-beg (car new-region) new-end (cdr new-region)))
c-before-context-fontification-functions))))
! (funcall c-standard-font-lock-fontify-region-function
new-beg new-end verbose)))
(defun c-after-font-lock-init ()
--- 1184,1190 ----
(setq new-region (funcall fn new-beg new-end))
(setq new-beg (car new-region) new-end (cdr new-region)))
c-before-context-fontification-functions))))
! (funcall (default-value 'font-lock-fontify-region-function)
new-beg new-end verbose)))
(defun c-after-font-lock-init ()
***************
*** 1195,1203 ****
;; function will get executed before the font-lock one. Amongst other
;; things.
(remove-hook 'after-change-functions 'c-after-change t)
! (add-hook 'after-change-functions 'c-after-change nil t)
! (setq c-standard-font-lock-fontify-region-function
! (default-value 'font-lock-fontify-region-function)))
(defun c-font-lock-init ()
"Set up the font-lock variables for using the font-lock support in CC Mode.
--- 1192,1198 ----
;; function will get executed before the font-lock one. Amongst other
;; things.
(remove-hook 'after-change-functions 'c-after-change t)
! (add-hook 'after-change-functions 'c-after-change nil t))
(defun c-font-lock-init ()
"Set up the font-lock variables for using the font-lock support in CC Mode.
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
2013-05-01 0:51 ` Glenn Morris
2013-05-01 3:37 ` Glenn Morris
@ 2013-05-01 6:51 ` Achim Gratz
1 sibling, 0 replies; 15+ messages in thread
From: Achim Gratz @ 2013-05-01 6:51 UTC (permalink / raw)
To: 14325
Glenn Morris writes:
> Minimal example:
>
> ./src/emacs -Q -batch --eval \
> '(progn (find-file "./src/emacs.c") (font-lock-fontify-buffer))'
>
> Ie, a use of font-lock that does not first call font-lock-mode-hook.
Why is that hook skipped? And what would be the correct workaround?
> This was already fixed once:
> http://lists.gnu.org/archive/html/emacs-diffs/2012-02/msg00114.html
>
> but reverted:
> http://lists.gnu.org/archive/html/emacs-diffs/2012-02/msg00348.html
>
> There was some kerfluffle about it:
> http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00380.html
I see… maybe a consensus might be reached this time.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
2013-04-30 17:45 ` bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch Achim Gratz
2013-05-01 0:51 ` Glenn Morris
@ 2013-05-01 12:53 ` Alan Mackenzie
2013-05-01 16:26 ` Achim Gratz
` (5 subsequent siblings)
7 siblings, 0 replies; 15+ messages in thread
From: Alan Mackenzie @ 2013-05-01 12:53 UTC (permalink / raw)
To: gnu-emacs-bug
Achim Gratz <Stromeko@nexgo.de> wrote:
> Publishing from Worg (the community webpages for Org) runs in batch mode
> and uses cc-mode for syntax highlighting for some source code examples.
> While testing the publishing process with Emacs?24 I've come across an
> apparent regression in cc-mode: it tries to use the initial value for
> c-standard-font-lock-fontify-region-function, which happens to be nil to
> do a funcall and errors out since the function slot of that variable is
> void. I've worked around the error by adding this to the init file:
> --8<---------------cut here---------------start------------->8---
> ;; to have things work correctly in batch-mode
> (require 'font-lock)
> (require 'cc-mode)
> (c-after-font-lock-init)
> --8<---------------cut here---------------end--------------->8---
> I cannot tell if that works correctly in all cases or why this is
> necessary, but simply by switching to Emacs?23 it all works correctly
> without it.
Yes, the c-after-font-lock-init call will initialise everything properly,
though it's more a workaround than a solution.
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.
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.
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)
.
However, you'll probably prefer to carry on with using Font Lock Mode
uninitialised. ;-) I think Glenn's patch achieves this painlessly.
> Regards,
> Achim.
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
2013-04-30 17:45 ` bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch Achim Gratz
2013-05-01 0:51 ` Glenn Morris
2013-05-01 12:53 ` Alan Mackenzie
@ 2013-05-01 16:26 ` Achim Gratz
2013-05-01 17:23 ` Alan Mackenzie
` (4 subsequent siblings)
7 siblings, 0 replies; 15+ messages in thread
From: Achim Gratz @ 2013-05-01 16:26 UTC (permalink / raw)
To: 14325
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
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
2013-04-30 17:45 ` bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch Achim Gratz
` (2 preceding siblings ...)
2013-05-01 16:26 ` Achim Gratz
@ 2013-05-01 17:23 ` Alan Mackenzie
2013-05-01 18:15 ` Achim Gratz
` (3 subsequent siblings)
7 siblings, 0 replies; 15+ messages in thread
From: Alan Mackenzie @ 2013-05-01 17:23 UTC (permalink / raw)
To: gnu-emacs-bug
Achim Gratz <Stromeko@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).
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
2013-04-30 17:45 ` bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch Achim Gratz
` (3 preceding siblings ...)
2013-05-01 17:23 ` Alan Mackenzie
@ 2013-05-01 18:15 ` Achim Gratz
2013-05-02 13:04 ` Alan Mackenzie
2013-05-02 18:44 ` Achim Gratz
` (2 subsequent siblings)
7 siblings, 1 reply; 15+ messages in thread
From: Achim Gratz @ 2013-05-01 18:15 UTC (permalink / raw)
To: 14325
Alan Mackenzie writes:
> OK. Could you possibly give the exact sequence of Font Lock and CC Mode
> calls which lead to the error?
If you can tell me how to obtain a trace in batch mode? Or if you
prefer to do this yourself, here's the call that makes the problem:
emacs -batch -Q -l worgtest-local-init.el -l worgtest-init.el \
org-hacks.org -f toggle-debug-on-error -f org-html-export-to-html
You need a local clone of Worg (or at least these three files), a recent
Org mode and deactivate the workaround in worgtest-init.el of course.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
2013-05-01 18:15 ` Achim Gratz
@ 2013-05-02 13:04 ` Alan Mackenzie
0 siblings, 0 replies; 15+ messages in thread
From: Alan Mackenzie @ 2013-05-02 13:04 UTC (permalink / raw)
To: Achim Gratz; +Cc: 14325
Hi, Achim.
On Wed, May 01, 2013 at 08:15:03PM +0200, Achim Gratz wrote:
> Alan Mackenzie writes:
> > OK. Could you possibly give the exact sequence of Font Lock and CC Mode
> > calls which lead to the error?
> If you can tell me how to obtain a trace in batch mode?
:-). I thought you knew the software. Never mind.
I've installed Glenn's patch into the Emacs trunk. Could you please try
it out, and see if it solves your problem.
> Regards,
> Achim.
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
2013-04-30 17:45 ` bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch Achim Gratz
` (4 preceding siblings ...)
2013-05-01 18:15 ` Achim Gratz
@ 2013-05-02 18:44 ` Achim Gratz
2013-05-05 14:17 ` Achim Gratz
2013-05-06 13:25 ` Alan Mackenzie
7 siblings, 0 replies; 15+ messages in thread
From: Achim Gratz @ 2013-05-02 18:44 UTC (permalink / raw)
To: 14325
Alan Mackenzie writes:
>> If you can tell me how to obtain a trace in batch mode?
>
> :-). I thought you knew the software. Never mind.
I do, but I don't know what are the differences in noninteractive mode.
Stepping through the code in interactive mode is possible, but I
wouldn't be able to tell if it goes through the same motions.
> I've installed Glenn's patch into the Emacs trunk. Could you please try
> it out, and see if it solves your problem.
I'll give it a whirl over the weekend (I hope).
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
2013-04-30 17:45 ` bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch Achim Gratz
` (5 preceding siblings ...)
2013-05-02 18:44 ` Achim Gratz
@ 2013-05-05 14:17 ` Achim Gratz
2013-05-06 13:25 ` Alan Mackenzie
7 siblings, 0 replies; 15+ messages in thread
From: Achim Gratz @ 2013-05-05 14:17 UTC (permalink / raw)
To: 14325
Alan Mackenzie writes:
> I've installed Glenn's patch into the Emacs trunk. Could you please
> try it out, and see if it solves your problem.
I've built a new Emacs from trunk today and the fix works as intended.
Thanks to you and Glenn.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 15+ messages in thread* bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch
2013-04-30 17:45 ` bug#14325: 24.3; cc-mode does not initialize correctly w/ -batch Achim Gratz
` (6 preceding siblings ...)
2013-05-05 14:17 ` Achim Gratz
@ 2013-05-06 13:25 ` Alan Mackenzie
7 siblings, 0 replies; 15+ messages in thread
From: Alan Mackenzie @ 2013-05-06 13:25 UTC (permalink / raw)
To: 14325-done
Bug fixed.
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 15+ messages in thread