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