GNU bug report logs -
#20146
font-lock-extend-jit-lock-region-after-change: results are discarded instead of being returned.
Previous Next
Reported by: Alan Mackenzie <acm <at> muc.de>
Date: Thu, 19 Mar 2015 23:03:02 UTC
Severity: normal
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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).
This bug report was last modified 5 years and 201 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.