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

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

[Ralf Angeli]

Hi,

in AUCTeX I am extending the region to be fontified by
`font-lock-default-fontify-region' backwards in order to cater for
large multiline constructs.  In order to force refontification with
jit-lock, `jit-lock-context-unfontify-pos' is set to the start of such
a multiline construct.  Now when this is done it seems that the
affected regions are refontified over and over again.

Here is a testcase:

(progn
  (defun my-font-lock-fontify-region (beg end &optional loudly)
    (setq jit-lock-context-unfontify-pos (- beg 1000))
    (message (format "Fontifying ... (buffer: %s, beg: %d)"
		     (prin1-to-string (current-buffer)) beg))
    (font-lock-default-fontify-region beg end loudly))
  (find-library "lisp-mode")
  (setq font-lock-fontify-region-function 'my-font-lock-fontify-region))

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.

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.

-- 
Ralf

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

[martin rudalics]

 > in AUCTeX I am extending the region to be fontified by
 > `font-lock-default-fontify-region' backwards in order to cater for
 > large multiline constructs.  In order to force refontification with
 > jit-lock, `jit-lock-context-unfontify-pos' is set to the start of such
 > a multiline construct.  Now when this is done it seems that the
 > affected regions are refontified over and over again.

That's the purpose of setting `jit-lock-context-unfontify-pos' when
`jit-lock-contextually' is non-nil.  jit-lock will trigger refontifying
the _entire visible_ text below `jit-lock-context-unfontify-pos' after
`jit-lock-context-time' seconds.

 >
 > Here is a testcase:
 >
 > (progn
 >   (defun my-font-lock-fontify-region (beg end &optional loudly)
 >     (setq jit-lock-context-unfontify-pos (- beg 1000))
 >     (message (format "Fontifying ... (buffer: %s, beg: %d)"
 > 		     (prin1-to-string (current-buffer)) beg))
 >     (font-lock-default-fontify-region beg end loudly))
 >   (find-library "lisp-mode")
 >   (setq font-lock-fontify-region-function 'my-font-lock-fontify-region))
 >
 > 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 ...

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

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

[Stefan Monnier]

> in AUCTeX I am extending the region to be fontified by
> `font-lock-default-fontify-region' backwards in order to cater for large
> multiline constructs.

I presume you don't use the font-lock-extend-region stuff because you need
it to work with Emacs<22, right?

> In order to force refontification with jit-lock,
> `jit-lock-context-unfontify-pos' is set to the start of such
> a multiline construct.

Huh?  In which circumstance do you see a need for such a setting?

Hmm...wait... my crystal ball here tells me that you forgot to set the
font-lock-multiline property from your font-lock-keywords.  is that right?
Please read the discussion about multiline and font-lock in the latest Emacs
manual (it's been significantly improved, so it should help, and if doesn't
help enough, then we should improve it more).


        Stefan

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

[Ralf Angeli]

* 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

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

[Ralf Angeli]

* Stefan Monnier (2007-04-24) writes:

>> in AUCTeX I am extending the region to be fontified by
>> `font-lock-default-fontify-region' backwards in order to cater for large
>> multiline constructs.
>
> I presume you don't use the font-lock-extend-region stuff because you need
> it to work with Emacs<22, right?

Yes.

>> In order to force refontification with jit-lock,
>> `jit-lock-context-unfontify-pos' is set to the start of such
>> a multiline construct.
>
> Huh?  In which circumstance do you see a need for such a setting?
>
> Hmm...wait... my crystal ball here tells me that you forgot to set the
> font-lock-multiline property from your font-lock-keywords.  is that right?

`font-lock-multiline' (the variable) is set to t.  And multiline
constructs also get the `font-lock-multiline' property.  But I
actually don't want to use `font-lock-multiline' for forward
fontification because it has often led to "color spill".  What I am
currently doing is to give up after a certain amount of forward
searching and give the tag probably starting an unfinished multiline
construct a warning color.  But that means that the mechanism using
the `font-lock-multiline' property won't find such a property at
boundaries of regions to be fontified.  That's why I have to look back
myself for the start of the construct and trigger refontification of
the region.

Anyway, I dug a bit in the archives of emacs-devel and found that I
got the hint about `jit-lock-context-unfontify-pos' from you, but
obviously didn't understand what you told me about its dangers.  You
specifically warned about such refontification loops,
cf. <URL:http://mid.gmane.org/jwvirrj7wwg.fsf-monnier+emacs%40gnu.org>.
Now I just need a way to make sure j-l-c-u-p is only set when "when
refontification will indeed make a difference".

> Please read the discussion about multiline and font-lock in the latest Emacs
> manual (it's been significantly improved, so it should help, and if doesn't
> help enough, then we should improve it more).

Will do.

-- 
Ralf

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

[Stefan Monnier]

> `font-lock-multiline' (the variable) is set to t.  And multiline
> constructs also get the `font-lock-multiline' property.  But I
> actually don't want to use `font-lock-multiline' for forward
> fontification because it has often led to "color spill".  What I am
> currently doing is to give up after a certain amount of forward
> searching and give the tag probably starting an unfinished multiline
> construct a warning color.

> But that means that the mechanism using the `font-lock-multiline' property
> won't find such a property at boundaries of regions to be fontified.

Check the Elisp Manual's discussion of multiline fontification.
You're confusing the identification and the re-highlighting.
The `font-lock-multiline' property is there to solve the
"re-highlighting" problem.  The problem you mention here is one of
"identification", and this one is not solved by font-lock-multiline indeed,
but by your f-l-fontify-region-function (or by f-l-extend-region).
So I still don't understand where/why you need
jit-lock-context-unfontify-pos.


        Stefan

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.

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

[Ralf Angeli]

* Stefan Monnier (2007-04-24) writes:

> Check the Elisp Manual's discussion of multiline fontification.

I did now.

> You're confusing the identification and the re-highlighting.
> The `font-lock-multiline' property is there to solve the
> "re-highlighting" problem.  The problem you mention here is one of
> "identification", and this one is not solved by font-lock-multiline indeed,
> but by your f-l-fontify-region-function (or by f-l-extend-region).
> So I still don't understand where/why you need
> jit-lock-context-unfontify-pos.

j-l-c-u-p seemed to be the only mechanism working reliably.  In my
f-l-fontify-region-function I tried to set the f-l-multiline and
j-l-defer-multiline properties on the region in question which had no
effect.  Setting the fontified property to nil in addition made it
work now.  I'm a bit short of time at the moment but will look at this
in more detail during the next days.

-- 
Ralf

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

[Ralf Angeli]

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

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

Thanks for the clarification.  I hope with your and Stefan's input I
will be able to fix the problem in a few days.  I will keep you
updated.

-- 
Ralf

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

[Stefan Monnier]

> j-l-c-u-p seemed to be the only mechanism working reliably.  In my
> f-l-fontify-region-function I tried to set the f-l-multiline and
> j-l-defer-multiline properties on the region in question which had no
> effect.

In your f-l-fontify-region-function, you should do what you'd otherwise do
in f-l-extend-region: i.e. extend the region.  No messing with
font-lock-multiline or other properties.  Just computing a new (larger)
region and passing that to f-l-default-fontify-region.

This is meant to make sure that if the region to highlight is part of
a larger multiline-element, it will be refontified in the proper context.

Then in font-lock-keywords, whenever you encounter a multiline element, you
want to mark it with the font-lock-multiline property.  This might work
automatically if you set the font-lock-multiline to t.

That should make sure that when a multiline element is later modified
(possibly turning it into something completely different), it is
completely refontified.

That should be enough to make it all work, regardless of the use of
jit-lock or even lazy-lock.

If it doesn't work, please give more details, including a sample session
where it fails and an explanation of how it fails.


        Stefan

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

[Ralf Angeli]

* Stefan Monnier (2007-04-25) writes:

>> j-l-c-u-p seemed to be the only mechanism working reliably.  In my
>> f-l-fontify-region-function I tried to set the f-l-multiline and
>> j-l-defer-multiline properties on the region in question which had no
>> effect.
>
> In your f-l-fontify-region-function, you should do what you'd otherwise do
> in f-l-extend-region: i.e. extend the region.  No messing with
> font-lock-multiline or other properties.  Just computing a new (larger)
> region and passing that to f-l-default-fontify-region.

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.

> If it doesn't work, please give more details, including a sample session
> where it fails and an explanation of how it fails.

In AUCTeX's LaTeX mode ``text in quotes'' will get highlighted.  If I
start a quote, move a page downwards and insert the ending quotation
marks, only part of the text in quotes will get the appropriate face
if j-l-c-u-p is not set.

I'll try to come up with a testcase demontrating this in a
programmatic way on Friday.

-- 
Ralf

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

[Stefan Monnier]

>>> j-l-c-u-p seemed to be the only mechanism working reliably.  In my
>>> f-l-fontify-region-function I tried to set the f-l-multiline and
>>> j-l-defer-multiline properties on the region in question which had no
>>> effect.
>> 
>> In your f-l-fontify-region-function, you should do what you'd otherwise do
>> in f-l-extend-region: i.e. extend the region.  No messing with
>> font-lock-multiline or other properties.  Just computing a new (larger)
>> region and passing that to f-l-default-fontify-region.

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


        Stefan

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

[martin rudalics]

 > In AUCTeX's LaTeX mode ``text in quotes'' will get highlighted.  If I
 > start a quote, move a page downwards

... here a function on `window-scroll-functions' should decide what to
do with such pending quotes - provided you're 100% sure that you cannot
turn them into strings syntactically spoken ...

 > and insert the ending quotation
 > marks, only part of the text in quotes will get the appropriate face
 > if j-l-c-u-p is not set.

... a function on `after-change-functions' would have to find the
matching starting quote and put a multiline property on the entire
quoted text.  Setting `jit-lock-context-unfontify-pos' doesn't make
sense here: If moving the page downwards moves the starting quote
_before_ `window-start' font-lock might not find it in the first place.

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

[martin rudalics]

 > In AUCTeX's LaTeX mode ``text in quotes'' will get highlighted.  If I
 > start a quote, move a page downwards

... here a function on `window-scroll-functions' should decide what to
do with such pending quotes - provided you're 100% sure that you cannot
turn them into strings syntactically spoken ...

 > and insert the ending quotation
 > marks, only part of the text in quotes will get the appropriate face
 > if j-l-c-u-p is not set.

... a function on `after-change-functions' would have to find the
matching starting quote and put a multiline property on the entire
quoted text.  Setting `jit-lock-context-unfontify-pos' doesn't make
sense here: If moving the page downwards moves the starting quote
_before_ `window-start' font-lock might not find it in the first place.

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

[Ralf Angeli]

* Stefan Monnier (2007-04-25) writes:

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

Anyway, below you can find the testcase I promised.  Just execute it
and type ''.  Then you should see that only the line where '' was
typed is highlighted.

If you uncomment the line setting j-l-c-u-p you should see that the
region gets highlighted after a short delay without having to type
`C-l'.

Here is the code:

(progn
  (defun my-match-quote (limit)
    (let (start)
      (when (setq start (search-forward "``" limit t))
	(if (search-forward "''" nil t)	; Do not limit forward search
					; for this testcase.
	    (progn (set-match-data (list start end)) t)
	  (set-match-data (list 0 0))))))
  (defun my-f-l-fontify-region (beg end &optional loudly)
    ;; For testing purposes we assume that the region should be extended
    ;; to the start of the buffer.
;;     (setq jit-lock-context-unfontify-pos 1)
    (font-lock-default-fontify-region 1 end loudly))
  (switch-to-buffer (get-buffer-create "*foo*"))
  (setq my-f-l-keywords '((my-match-quote . font-lock-string-face)))
  (setq font-lock-defaults '(my-f-l-keywords))
  (setq font-lock-fontify-region-function 'my-f-l-fontify-region)
  (insert "``")
  (dotimes (i 1000) (insert "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n"))
  (font-lock-mode 1)
  (backward-char))

-- 
Ralf

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

[Ralf Angeli]

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

>  > In AUCTeX's LaTeX mode ``text in quotes'' will get highlighted.  If I
>  > start a quote, move a page downwards
>
> ... here a function on `window-scroll-functions' should decide what to
> do with such pending quotes - provided you're 100% sure that you cannot
> turn them into strings syntactically spoken ...

IIRC I decided to leave fontification of quoted text to font lock
keywords because like that I can test if the quote is e.g. in a
LaTeX verbatim environment and disregard it in such a case.

>  > and insert the ending quotation
>  > marks, only part of the text in quotes will get the appropriate face
>  > if j-l-c-u-p is not set.
>
> ... a function on `after-change-functions' would have to find the
> matching starting quote and put a multiline property on the entire
> quoted text.

Yes.  I think my first try with `after-change-functions' was to advise
`jit-lock-after-change' and extend the region right there.

> Setting `jit-lock-context-unfontify-pos' doesn't make
> sense here: If moving the page downwards moves the starting quote
> _before_ `window-start' font-lock might not find it in the first place.

The `font-lock-fontify-region-function' calls functions to extend the
region backwards.  So this should not be an issue.  In the example
code I sent before I did not use such extension functions (I assumed
the region starts at the beginning of the buffer instead) but I hope
it makes the concept clearer nevertheless.

-- 
Ralf

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

[Stefan Monnier]

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

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

[Ralf Angeli]

* Stefan Monnier (2007-04-27) writes:

>> 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:
[...]

Thanks very much for the explanations.

> So in your case you can either use
> jit-lock-after-change-extend-region-functions;

Unfortunately this hook is not available in Emacs 21.

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

This is probably the way to go.  I tried this and it works very well.
(For Emacs 21 I put the contents of `jit-lock-force-redisplay' into an
anonymous function passed to `run-with-timer'.)

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

That would be nice, yes.  For now I am relieved that this could be
solved from within AUCTeX as well.

Thank you very much for your valuable help.

-- 
Ralf

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

[Ralf Angeli]

* Stefan Monnier (2007-04-27) writes:

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

By the way, `jit-lock-force-redisplay' uses the macro
`with-buffer-prepared-for-jit-lock' which is only defined when
jit-lock.el is being compiled.  Is there a way to use that macro from
outside of jit-lock.el?  A `(require 'jit-lock)' does not help.

-- 
Ralf

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

[Stefan Monnier]

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

> By the way, `jit-lock-force-redisplay' uses the macro
> `with-buffer-prepared-for-jit-lock' which is only defined when
> jit-lock.el is being compiled.  Is there a way to use that macro from
> outside of jit-lock.el?  A `(require 'jit-lock)' does not help.

It'd probably be better to not bother with the "feature" of only
defining that macro when compiling.  But in the mean time (and to work with
older Emacsen), you may want to (eval-when-compile (load "jit-lock.el")).
Yuck :-(


        Stefan


PS: Of course you can also use your own copy of the macro.

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

[Ralf Angeli]

* Stefan Monnier (2007-04-30) writes:

>> By the way, `jit-lock-force-redisplay' uses the macro
>> `with-buffer-prepared-for-jit-lock' which is only defined when
>> jit-lock.el is being compiled.  Is there a way to use that macro from
>> outside of jit-lock.el?  A `(require 'jit-lock)' does not help.
>
> It'd probably be better to not bother with the "feature" of only
> defining that macro when compiling.  But in the mean time (and to work with
> older Emacsen), you may want to (eval-when-compile (load "jit-lock.el")).
> Yuck :-(
[...]
> PS: Of course you can also use your own copy of the macro.

Thanks.  What I did now is put the expanded contents of
j-l-force-redisplay (including the code from the macros) into a
compatibility function (which calls j-l-force-redisplay when
available).

-- 
Ralf