bug#20146: font-lock-extend-jit-lock-region-after-change: results are discarded instead of being returned.

[Alan Mackenzie <acm@muc.de>]

Hi, Stefan.

On Fri, Mar 20, 2015 at 10:29:16PM -0400, Stefan Monnier wrote:
> >> No the core of the API is font-lock-fontify-region and it should work
> >> with *any* bounds (i.e. if these need to be extended, it should be done
> >> by font-lock-extend-region-function).
> > However, when the bounds are set by the major mode, those bounds should
> > be respected by Font Lock.

> The major mode sets font-lock-extend-region-function and this functions'
> result should be (and is) respected by the rest of font-lock.

If only, but this is simply not the case at the moment.
jit-lock-fontify-now has a hard-coded extension to whole lines,
regardless of the contents of font-lock-extend-region-functions.  It is
this hard-coded extended region that jit-lock-fontify-now passes to
font-lock-fontify-region, which then attempts to extend this region
further.

This is surely a bug.

           ;; Until someone has a better idea, let's start
           ;; at the start of the line containing START and
           ;; stop at the start of the line following NEXT.

As a better idea, why not have jit-lock-fontify-now use
f-l-extend-region-functions, and then pass the original `start' and
`next' to f-l-fontify-region.  That way, we would be sure that the two
functions, one setting/clearing text properties, the other doing the
fontification, would actually be working on the same portion of the
buffer.  It would bring jit-lock closer to behaving the same as
unassisted font-lock.  And it would allow a major mode to set an
arbitrary font-lock region, of course.

> But callers of font-lock-fontify-region (such as
> font-lock-after-change-function, or jit-lock) can choose *any* bounds
> they feel like and font-lock-fontify-region should behave correctly.

This seems to be true.  When I (setq font-lock-support-mode nil), things
seem to behave properly.  It seems a poor workaround, though.

[ ... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).