all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Ralf Angeli <angeli@caeruleus.net>
Cc: emacs-devel@gnu.org
Subject: Re: Excessive refontification when setting jit-lock-context-unfontify-pos
Date: Fri, 27 Apr 2007 14:54:00 -0400	[thread overview]
Message-ID: <jwvy7kdekcq.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87k5vxvh4x.fsf@neutrino.caeruleus.net> (Ralf Angeli's message of "Fri\, 27 Apr 2007 19\:53\:02 +0200")

>>> 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	other threads:[~2007-04-27 18:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-23 19:44 Excessive refontification when setting jit-lock-context-unfontify-pos Ralf Angeli
2007-04-24  8:33 ` martin rudalics
2007-04-24 18:16   ` Ralf Angeli
2007-04-24 20:56     ` martin rudalics
2007-04-24 21:25       ` Ralf Angeli
2007-04-24 14:18 ` Stefan Monnier
2007-04-24 18:31   ` Ralf Angeli
2007-04-24 20:41     ` Stefan Monnier
2007-04-24 21:20       ` Ralf Angeli
2007-04-25  4:22         ` Stefan Monnier
2007-04-25  6:34           ` Ralf Angeli
2007-04-25  7:28             ` Stefan Monnier
2007-04-27 17:53               ` Ralf Angeli
2007-04-27 18:54                 ` Stefan Monnier [this message]
2007-04-27 21:11                   ` Ralf Angeli
2007-04-28 15:27                   ` Ralf Angeli
2007-04-30  0:23                     ` Stefan Monnier
2007-04-30  6:33                       ` Ralf Angeli
2007-04-25  8:18             ` martin rudalics
2007-04-27 18:02               ` Ralf Angeli
2007-04-25  8:27             ` martin rudalics

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=jwvy7kdekcq.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=angeli@caeruleus.net \
    --cc=emacs-devel@gnu.org \
    /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.