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
Message #20 received at 20146 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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. You don't need
fine-grained control over the font-lock region. You need better cache
invalidation.
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.
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.
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.
Maybe we should have some tests that do fontification one character at a
time, or in random order.
[signature.asc (application/pgp-signature, attachment)]
This bug report was last modified 5 years and 202 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.