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

[Alan Mackenzie]

Hello, Daniel.

On Fri, Mar 20, 2015 at 06:06:55PM -0700, Daniel Colascione wrote:
> On 03/20/2015 05:00 PM, Alan Mackenzie wrote:
> >> 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.

> Level-triggered fontification is the only correct scheme.

Can you offer any evidence, or argumentation for this opinion?  As I
said, edge-triggered fontification works in AWK Mode and works well.  I'm
not quite sure at the moment whether the other CC Mode modes use it.

> You don't need fine-grained control over the font-lock region.

Major modes need absolute control over where font-locking analysis starts
- they must be able to chose a position with a neutral syntactic context.
For example, when Font Lock asks for fontification starting in the
inside of a C++ declaration, C++ Mode needs to be able to say STOP!  GO
BACK!  CARRY ON!

> You need better cache invalidation.

When, where, of what?

> Font-lock can ask for the right to ask for the fontification of any
> range of characters. If I want to, I can install customization that
> changes the font-lock region to a whole paragraph, a whole defun, or a
> whole file. None of that should matter.

Of course.  But AFTER that selection, the major mode decides where to
start analysing based on the selection.  As I pointed out to Stefan, we
don't distinguish between "place to start analysing" and "place to start
applying face properties", so we can only talk about "the Font Lock
region".  I think the critical point is:  Several things can choose,
expand (?or contract) a region to fontify.  But the major mode must be
the last entity that does so.

> Some modes might have caches that reflect buffer contents --- they
> should invalidate these caches in before- and after-change-functions,
> before font-lock even runs.

Not quite sure exactly what sort of caches you're thinking about, but
they will get updated, rather than invalidated, in the
before/after-change-functions functions, surely?

> Let me put it another way: a highlighter's job is to find the correct
> face for a given buffer position. In order to not drive the user insane,
> that face must be a function solely of the contents of the buffer and
> cached information about the contents of the buffer. Otherwise,
> fontification will change depending on scrolling, jit-lock chunk size,
> and other factors. None of these things should affect the faces that we
> ultimately apply to characters.

Of course.  But they affect the way we calculate those faces.

> Maybe we should have some tests that do fontification one character at a
> time, or in random order.

Now there's an idea.  :-)

-- 
Alan Mackenzie (Nuremberg, Germany).