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

Previous Next

Full log

Message #38 received at 20146 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 20146 <at> debbugs.gnu.org
Subject: Re: bug#20146: font-lock-extend-jit-lock-region-after-change:
 results are discarded instead of being returned.
Date: Sat, 21 Mar 2015 21:03:25 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.