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

[Daniel Colascione <dancol@dancol.org>]

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]