Re: font-lock-extend-region

[Stefan Monnier]

> OK.  Yes, I think I agree with you now - the font-lock-multiline property
> could indeed do this job successfully (that's assuming it can be set on
> an arbitrary sequence of characters, not just on entire lines).

This assumption is valid.  Actually,the exact chars on which the
font-lock-multiline property is added is something important (e.g. you'd
have to include the \n after the \\).

> It is marginally less good than f-l-e-r-function in one extreme case:
> when the extended after-change region is large, and consists of two
> contiguous "atomic" ranges.  f-l-multiline would force jit-lock to fontify
> this atomically, whilst f-l-e-r-function would allow
> jit-lock-extend-chunk-function to fontify it as two chunks.

No, jit-lock would not be forced to refontify both chunks atomically at the
same time.  Remember jit-lock only deals with what needs to be refontified
(i.e. point (i) in your earlier email) then chunkifies it.
Only font-lock-default-fontify-region cares about atomicity (point (ii) in
your earlier email).

> I still think that f-l-extend-region-f is a more natural approach - IMAO,
> it is easier for a major mode to use.

I guess it's a matter of taste rather.  Often, you can put the
font-lock-multiline property very cheaply at the time you're highlighting
the multiline element, so you don't need to do any extra work at all to
discover its boundaries.  In contrast when using f-l-extend-region-f you may
have to re-discover the boundaries that you had found last time you
highlighted the element.

Furthermore, as you've discovered, if you use f-l-extend-region-f you get
into trouble when the time comes to refresh an element that used to be
multiline but isn't any more: you have to somehow figure out that it was
multiline earlier, then find the boundaries it had, then tell jit-lock that
this also needs to be refontified.  So you end up needing
a before-change-function, and an after-change-function, ...
Whereas with font-lock-multiline the problem doesn't even appear because it
uses text properties to remember the earlier multilineness of the element.

> Whatever we do, I think we are agreed that we need a major-mode supplied
> function that will extend a jit-lock chunk (as opposed to an after-change
> region).

The more I think about it, the less I'm convinced it's worth the trouble.
I didn't think hard about the design of font-lock-multiline when
I implemented it, but it turns out it works really well for what it's
designed to do.

>> When the redisplay engine calls jit-lock-function with arg 1055, it has
>> already redisplayed all the text until 1054 and changes in the buffer that
>> affect text before 1055 will not cause redisplay to restart when
>> it finishes.

> Ah, got it!  Thanks!

> Maybe the extension-to-whole-lines needs to stay in jit-lock-fontify-now
> (since _something_ has to clear the 'fontified text property), and it has
> to stay in f-l-default-f-region (since jit-lock isn't always enabled).
> That only leaves the after-change one to take out.  Maybe.

The above problem to which you replied "Ah, I got it" is the one that's
solved in the after-change function, so no: we can't take out the one in
after-change-function.

Clearing the `fontified' property is not a good justification for the
code in jit-lock-fontify-now.  I really think this one can go.
OTOH I think it'd be good if font-lock could return to jit-lock the extent
of the area that was actually refreshed (including extension due to
font-lock-multiline), so that jit-lock can clear more of the `fontified'
property and avoid some redundant font-locking.


        Stefan