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

[martin rudalics]

> After scrolling through the whole buffer everything obviously is
> fontified.

Without

(setq jit-lock-context-unfontify-pos (- beg 1000))

it is.  Setting `jit-lock-context-unfontify-pos' will trigger a timer
which eventually will reset the fontified property to nil for every
character following `jit-lock-context-unfontify-pos'.

> So I am wondering why the function behind
> `font-lock-fontify-region-function' is being called even though there
> is no need for it.

Because you told it to do so.

> With the test case this happens when you reach the
> buffer end and will eventually stop when scrolling back up.

`font-lock-fontify-region-function' may have been called with `beg'
equalling `window-start' and you set `jit-lock-context-unfontify-pos' to
some position 1000 characters before window-start.  After
`jit-lock-context-time' seconds `jit-lock-context-fontify' will reset
fontified to nil for the entire text between that position and
`point-max'.  Every subsequent redisplay will refontify the visible text
and set `jit-lock-context-unfontify-pos' to some position before visible
text again, causing fontification to loop forever.

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

You would have to explain this more precisely.  Maybe adding something
to `window-scroll-functions' and/or `window-configuration-change-hook'
will help.