Re: font-lock-extend-region

[Alan Mackenzie]

Hi, Stefan!

On Tue, 21 Mar 2006, Stefan Monnier wrote:

>>>> What I think we need is a function called from f-l-default-f-region
>>>> which will get a safe starting position at or before L1034.

>>> Agreed.  And I suggested we name it font-lock-extend-region-function.

>> font-lock-extend-region-function is already in use for purpose (i),
>> determining the region to be fontified.

>Yes, I understand that, but I'm trying to understand why you need it and
>whether font-lock-extend-region-function is then the right answer.

I think it's the right answer.

>> I'm saying we also need a distinct function for purpose (ii),
>> determining a safe place to start fontifying a chunk which could
>> easily be in the middle of the region returned by (i).

>I think I need to start over.  IIUC you're trying to handle the "\\\n"
>line-continuation feature, right?

Yes, in essence.

>For that, you need to always font-lock the whole multiline-line at a
>time, right?  So my natural answer (given the hammer I have in my hand)
>is to tell you to put a font-lock-multiline property on the whole
>multiline-line.  My naive understanding says that it should be
>sufficient: no need for font-lock-extend-region anywhere.

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

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

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).  Maybe jit-lock-extend-chunk-function taking two arguments, BEG
and END?

[ .... ]

[ talking about the number of times a fontification region is extended to
entire lines:]
>> I think any text region handled by jit-l-f-now cannot avoid being
>> processed by f-l-fontify-region.

>Indeed, as I said, I think it can be removed, although of course we'll then
>have to update glasses-mode first (which registers itself with jit-lock).
>I think glasses-mode and font-lock-mode are the only two to use jit-lock.

>> I don't see this, yet.  If 'fontified is cleared only on the new open
>> paren at position 1055, the display engine calls successively
>>   (jit-lock-function 1055),
>>   (jit-lock-fontify-now 1055 1555),
>>     and (assuming j-l-f-now DOESN'T extend to whole lines)
>>   (run-hook jit-lock-functions 1055 1555),
>>   (font-lock-fontify-region 1055 1555),
>>   (funcall font-lock-fontify-region-function 1055 1555),
>>   (font-lock-default-fontify-region 1055 1555).
>> Here, in f-l-default-f-r, 1055 is set back to 1044 (BOL), and this whole
>> line, 1044 - 1056, gets its face properties rearranged.

>You're right until here.

>> These then get redisplayed.

>But this is what doesn't happen.

>> What am I missing here?

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

>        Stefan

-- 
Alan.