From: Alan Mackenzie <acm@muc.de>
To: Hannu Koivisto <azure@iki.fi>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: First fontification of a buffer happens before font lock is fully initialised.
Date: Wed, 25 Jan 2012 20:22:49 +0000 [thread overview]
Message-ID: <20120125202249.GC3624@acm.acm> (raw)
In-Reply-To: <83vcnzy4c3.fsf@kalahari.s2.org>
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).
next prev parent reply other threads:[~2012-01-25 20:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-25 12:48 First fontification of a buffer happens before font lock is fully initialised Alan Mackenzie
2012-01-25 17:46 ` Stefan Monnier
2012-01-25 18:26 ` Alan Mackenzie
2012-01-25 19:22 ` Hannu Koivisto
2012-01-25 20:22 ` Alan Mackenzie [this message]
2012-01-26 1:43 ` Stefan Monnier
2012-01-26 10:58 ` Alan Mackenzie
2012-02-04 12:03 ` Alan Mackenzie
2012-02-06 1:39 ` Stefan Monnier
2012-02-07 10:10 ` Alan Mackenzie
2012-02-07 18:02 ` Stefan Monnier
2012-02-08 21:43 ` Alan Mackenzie
2012-02-10 14:27 ` Stefan Monnier
2012-02-23 11:39 ` Alan Mackenzie
2012-02-23 14:34 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120125202249.GC3624@acm.acm \
--to=acm@muc.de \
--cc=azure@iki.fi \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.