Re: Excessive refontification when setting jit-lock-context-unfontify-pos

[Ralf Angeli <angeli@caeruleus.net>]

* martin rudalics (2007-04-24) writes:

>  > After executing the form lisp-mode.el should be opened and the
>  > `font-lock-fontify-region-function' will be set to the new one defined
>  > in the code which always sets `jit-lock-context-unfontify-pos'.  If
>  > you now scroll to the bottom of the buffer with `C-v' the function
>  > obviously gets called a lot.  But once the bottom of the buffer is
>  > reached I'd expect that to stop unless something changed in the
>  > buffer.  However, only some activity like scrolling or activating the
>  > minibuffer will make the fontification function be called again.
>
> Everything's correct.  Scrolling will move you into some text marked as
> not fontified and will trigger fontification from there which will, due
> to your setting, eventually mark the text as not fontified again, which
> will ...

After scrolling through the whole buffer everything obviously is
fontified.  So I am wondering why the function behind
`font-lock-fontify-region-function' is being called even though there
is no need for it.  With the test case this happens when you reach the
buffer end and will eventually stop when scrolling back up.

>  > This does not happen in Emacs 21, so it looks like this is a
>  > regression.  I got a bit tangled up in the font-lock and jit-lock code
>  > and hope that somebody has an idea of what might be going wrong.
>
> It's the desired behavior.  `jit-lock-context-unfontify-pos' should be
> set by jit-lock only.  You are supposed to set this only in extreme
> cases and exercise care to never set this repeatedly.  Why can't you use
> font-lock's new extend-region stuff for this purpose?

Because I need a mechanism which works in Emacs 21 and XEmacs as
well.  I thought about using an after-change function but this does
not help when a chunk of text is being fontified by jit-lock and I
need to look backwards for the start of a multiline construct when no
change happened before.

-- 
Ralf