Re: Last steps for pretesting (font-lock-extend-region-function)

[Alan Mackenzie <acm@muc.de>]

Hi, Stefan!

On Wed, 26 Apr 2006, Stefan Monnier wrote:

>>> I'm not saying the hook is a kludge: I'm saying the code that uses it is
>>> a kludge, compared to the code that uses font-lock-multiline.

>> OK.  I feel that existing code in AWK Mode is natural.  (OK, I wrote it,
>> so I'm not in a position to judge it dispassionately, but ...).  It notes
>> the logical EOL before a change.  It notes the logical EOL after a
>> change.  The later one is the end position for fontification.

>Why doesn't the BOL before change matter?

Maybe it does/would do in some major modes.  It happens not to have any effect
in AWK.

>Why does the EOL before change matter?

Because a buffer change can alter this EOL's syntactic context.

>> By contrast, the f-l-multiline method (ab)uses the structure for setting
>> face properties to set region boundaries for possible future changes.

>Abuses the structure of what?

font-lock-keywords.  The purpose of this structure is to fontify strings
matching specific regular expressions.  Using it to expand the region to
be font-locked at a future fontification seems utterly disconnected with
this purpose.

>There two issues about multiline elements:
>- properly notice them when they appear
>- properly *re*fontify them when they change

I cannot bring myself to consider the extension of a font lock region as
"the manipulation of a multiline element".  It just feels too contorted.
I have always understood the term "multiline element" to mean an element
within the font-lock region which crosses a line boundary.  [Such things
occur a lot in Texinfo Mode, for example, and turning on the
f-l-multiline variable does indeed make these elements fontify properly.]

>The first is taken care of by font-lock-fontify-region-function.

The AWK Mode regular expressions, even those that can straddle line
breaks, match just fine without having to turn on the f-l-multiline
variable. 

>The second talks about *re*fontification, so it's natural that it would
>involves saving some info during fontification for the next time around.

I think I would agree, except that font-lock brutally erases these
properties at every fontification, only to have to recalculate them.
This wastes processor time, probably quite a lot of it.  What is the
point of doing this, unless there has been a buffer change?  The same
applies to the syntax-table property.

>Doing it in a-c-f is fundamentally not the right place since it doesn't
>know whether and how the changed text was fontified: it works, of
>course, but it's not particularly more natural.

To know how text is to be refontified, you need to know how it has been
changed.  before/after-change-functions is a perfectly natural place to
find this out.

>        Stefan

-- 
Alan.