Re: First fontification of a buffer happens before font lock is fully initialised.

[Hannu Koivisto <azure@iki.fi>]

Alan Mackenzie <acm@muc.de> writes:

> Hello, Stefan.
>
> On Wed, Jan 25, 2012 at 12:46:04PM -0500, Stefan Monnier wrote:
>> > This situation was found and analysed by Hannu Koivisto after CC Mode
>> > crashed for this reason on a C++ buffer.  Why it doesn't happen for
>> > every CC Mode buffer is not yet clear.

Indeed yesterday, after my initial report, I debugged the problem a
bit more and also noticed that it happens with some files but not
with others.  It seemed that there was asynchronous behaviour at
play that might explain that but I didn't have time to track why
the asynchronity happened with some files but with others
font-lock-mode ended up calling font-lock-fontify-buffer before
running the hooks.

>> I think the behavior depends on the use of font-lock-support-mode.
>> With jit-lock, fontification takes place after running the mode-hook,
>> whereas without it, fontification takes place before.

So do you agree that the code should be changed so that
fontification always happens after running the mode-hook?

> Surely this cannot be - the hooks are run at the end of the
> define-minor-mode expansion no matter what.  Surely the hooks are not
> being run twice.  Though I admit I haven't tracked down the stages in
> initialising jit-lock-mode.
>
> Hannu's bug report said nothing about disabling jit-lock, so I presume it
> was enabled.

I didn't talk about my configuration at all because I was hoping to
eventually reproduce the problem starting with emacs -q if my
observation about what I felt was clearly problematic call chain
didn't lead to a fix.  My configuration uses lazy-lock.  Gladly I
can see from your mail to bug-cc-mode that you have been able to
reproduce the problem with emacs -q and font-lock-support-mode set
to nil with small files.

I'd guess that with lazy-lock it decides to postpone fontification
with some files but not with others.  I can't help but wonder why
the problem doesn't occur with all files when
font-lock-support-mode is set to nil.  Then again, I don't know
what font-lock-support-mode being nil really means, I'm just
assuming that in that case fontification should never be postponed.

-- 
Hannu