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
next prev parent 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.