Re: font-lock-extend-region

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> The region is not automatically marked with font-lock-multiline, so you
>> can't really fault font-lock-multiline for it: it's your code that marks it
>> that is at fault.
>> [ Now don't get me wrong: the font-lock-multiline property is not perfect. ]

> Hang on a moment!  The CC Mode code _doesn't_ currently mark text with
> font-lock-multiline.  I understood your suggestion was that it should do
> this.

My response was to your complaint about font-lock-multiline because of what
would happen if the C mode placed a font-lock-multiline on the whole 20K of
yanked text.  I understand that C mode doesn't do that right now.

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

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.

>> Or is there some other reason to extend the region from
>> after-change-functions, other than atomic elements at the boundaries?
> The region sometimes has to be extended to the end of what was an atomic
> element before the change, but is no longer so.

If this previously-atomic element had a font-lock-multiline property, then
it will be refontified atomically (at which point it will be discovered
that it's not atomic anymore so the font-lock-multiline property won't be
preserved).

>> I believe the one in jit-lock-fontify-now could be removed (but this
>> function is also sadly called from external packages, so there may be some
>> minor compatibility issues).
> 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.


        Stefan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642