emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: Re: Excessive refontification when setting jit-lock-context-unfontify-pos
Date: Fri, 27 Apr 2007 14:54:00 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.97 (gnu/linux)

>>> That's what I do.  (See `font-latex-fontify-region'.)  But the
>>> multiline construct does not get fully highlighted if I don't set
>>> j-l-c-u-p or set the fontified property to nil.
>> 
>> Try C-l to make sure that the highlighting is really absent from the buffer,
>> rather than merely being "not yet displayed".

> When typing `C-l' highlighting appears.  Is there a possibility to
> enforce such redisplay in an efficient way?  I could probably call
> `sit-for' somewhere in the code but I am not sure if this would be the
> right way.

I understand the problem, then.  Your code is working fine, it's just that
some part of the text your re-highlight is re-highlighted by jit-lock but
*after* having been rendered by the redisplay engine.
Typically it works like this:

1 - you modify buffer on line starting at position POS
2 - the redisplay engine see that there's nothing to do before POS,
    and calls jit-lock starting at POS.
3 - jit-lock calls font-lock, asking it to refontify region POS..POS+N
4 - font-lock decides to extend the region to POS-M1 .. POS+N+M2
5 - after highlighting is done, control returns to the redisplay which goes
    on to render POS .. POS+N.

The text between POS-M1 and POS has been refontified but the display does
not (yet) reflect it.

jit-lock has code already to handle similar problems, but the code doesn't
handle this case yet (basically because font-lock currently does not tell
jit-lock that it has extended the region).

The relevant code is in jit-lock-fontify-now:

           ;; The redisplay engine has already rendered the buffer up-to
           ;; `orig-start' and won't notice if the above jit-lock-functions
           ;; changed the appearance of any part of the buffer prior
           ;; to that.  So if `start' is before `orig-start', we need to
           ;; cause a new redisplay cycle after this one so that any changes
           ;; are properly reflected on screen.
           ;; To make such repeated redisplay happen less often, we can
           ;; eagerly extend the refontified region with
           ;; jit-lock-after-change-extend-region-functions.
           (when (< start orig-start)
             (run-with-timer 0 nil 'jit-lock-force-redisplay
                             (current-buffer) start orig-start))

So in your case you can either use
jit-lock-after-change-extend-region-functions; or you can use a similar
run-with-timer in your font-lock-fontify-region-function.  If you look at
jit-lock-force-redisplay, you'll see that it should not cause infinite
looping because it only causes redisplay (like C-l would) but not
re-highlighting.

Of course you can also indeed use jit-lock-context-unfontify-pos, but it has
the disadvantage of causing an unnecessary refontification and requires
extra care to avoid infinite looping.  Also it introduces a delay.

In Emacs>22 we should fix the font-lock/jit-lock interface so that jit-lock
can handle this case automatically.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]