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

[Alan Mackenzie <acm@muc.de>]

Hi, Hannu.

On Wed, Jan 25, 2012 at 09:22:52PM +0200, Hannu Koivisto wrote:
> Alan Mackenzie <acm@muc.de> writes:

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

It will only happen on the first file (or a initial sequence of files),
since it is a global variable not being set which triggered the crash.

Looking at lazy-lock.el, there appears to be a minimum size below which
lazy-lock won't be active.  That size is 25,600 by default.  Could it be
that files smaller than this cause the crash, files bigger don't?

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

Yes, absolutely.

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

Pretty much.

> -- 
> Hannu

-- 
Alan Mackenzie (Nuremberg, Germany).