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

[Alan Mackenzie <acm@muc.de>]

Hello again, Stefan.

On Fri, Mar 20, 2015 at 03:39:10PM -0400, Stefan Monnier wrote:
> > Perhaps we could implement the convention that when a major mode has
> > positively set the font-lock region's start and end points, these should
> > be accepted by F/J-lock, but when not, F/J-lock should be free to alter
> > them (as it typically does now).

> 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.  As I pointed out to Daniel, the major mode is
the expert in where font-locking must start whereas Font Lock itself is
just an enthusiastic amateur, completely lacking the structural knowledge
the major mode has of the buffer.

> Jit-lock is implemented on top of that API and is hence free to use any
> bounds it sees fit.

But surely not to pass bounds to the major mode that the major mode must,
for a second time, adjust.  This is crazy.

> If you rely on more specific bounds being passed to
> font-lock-fontify-region, that means you have a problem on your side.

There is a problem, yes, but on which side it is is a matter for
discussion.  CC Mode has always relied on the specific bounds that it
provides.  This is the whole point of the 2006 interface.

You yourself pointed out that CC Mode is the sole user of the
functionality for expanding FL regions.  The main point of expanding
these regions, from CC Mode's point of view is to instruct Font Lock
where to begin, so that CC Mode's font-locking then functions correctly.

If CC Mode cannot rely on Font Lock being obedient, then it must
internally store the correct starting and ending points and somehow
substitute these for the inaccurate ones supplied by Font Lock.

> > The existence of font-lock-extend-after-change-region-function makes
> > this distinction possible.

> The existence of font-lock-extend-after-change-region-function is an
> error on my part (More specifically the result of a weakness on my part:
> when you requested this feature, I added
> font-lock-extend-region-function (which was the right fix) and
> reluctantly accepted to also add
> font-lock-extend-after-change-region-function just out of tiredness of
> arguing that it was the wrong solution).

Yes, it was an exhausting discussion back in 2006.  But
f-l-extend-after-change-r-f works well.  If you change the interface to
have only font-lock-extend-region-functions, then you rule out what
somebody (was it Daniel?) recently called "edge triggered" fontification,
leaving only "level triggered".

AWK Mode (if not others) uses edge triggered fontification:  For the
calculation of its FL region, it uses `beg' and `end' from
before-change-functions and `beg', `end', and `old-len' from
after-change-functions.  If f-l-extend-after-change-r-f vanishes, some
other means will have to be found to transmit this info to Font Lock -
the ugly advice used by earlier Emacs versions, for example.


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).