Re: font-lock-extend-region-function: Final refinements.

[Alan Mackenzie]

Morning, Stefan!

[ cc: emacs-devel added.]

On Thu, Aug 03, 2006 at 02:43:23PM -0400, Stefan Monnier wrote:
> > One small point - there are slightly different mechanisms in
> > jit-lock-after-change and font-lock-after-change-function for
> > extending the region.  Is there a reason for this?

> Yes.

> Basically here is what happens in f-l-after-change:
> A1 - obey f-l-extend-after-change-function.

> Here is what happens in j-l-after-change (via
> f-l-extend-jit-lock-region-after-change):
> B1 - obey f-l-extend-after-change-function.
> B2 - obey font-lock-multiline (just once: no looping).
> B3 - round up to whole lines.

> - A1 == B1.

That's not quite true.  B1 uses j-l-after-change-extend-region-functions,
which has the same purpose as f-l-extend-after-change-function, but a
different calling convention.  I can't see any reason why these two need
to be different - it seems to be an unnecessary complication.

font-lock-extend-region-functions uses yet a third calling convention,
although what it is doing is almost (but not quite) the same as A1 and
B1.

Could we not decide on the one or the other calling convention and use it
in both places?  At the very least, could we not use just one pair of
variables rather than both `font-lock-beg/end' and `jit-lock-start/end'?
With both pairs of variables, I can foresee lots of major mode code
ugliness like this:

   (set (if from-jit-a-c 'jit-lock-start 'font-lock-beg) construct-start)

> - B3 is only present so as to avoid double redisplay.  I.e. it's not needed
>   for correctness.  It could/should be replaced by the same code as what is
>   done in f-l-default-fontify-region, except that would be potentially
>   too costly.
> - B2 OTOH is important: it's the main way font-lock-multiline works: it
>   marks the part of the text that will need to be refontified before being
>   redisplayed.  It does not care about it being refontified atomically,
>   which is why it does not loop.

> Why is there no corresponding A2?  Because f-l-after-change ends up
> calling f-l-fontify-region where f-l-multiline is obeyed anyway.

I've thought this over for some time, and I'm convinced that's all
right.

> Note that the use of f-l-multiline in f-l-fontify-region is not
> reliable: it's basically using it to do /identification/ which is
> known not be reliable, but experience shows that it can be useful to
> do it, so that if a piece of text does get identified somehow at some
> point, its multilineness will usually be preserved.

I can't see that it's unreliable, but I'll take your word for it.  The
lack of f-l-multiline (or like-minded hook function) is what fouled up
the highlighting in the example I gave a day or two ago, after 500
bytes:

[This one:
#ifndef VMS   /* VMS hates multi-line '#if's */
# if !defined(ibm032)                    && \
     !defined(__convex__)                &&          \
     !(defined(vax) && !defined(ultrix)) &&           \
...
...
]

I agree with you that f-l-multiline needs to be checked in
f-l-fontify-region.

>         Stefan

-- 
Alan.