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: 4960 bytes --]



On 03/21/2015 03:58 AM, Alan Mackenzie wrote:
> 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.

If fontification depends on recent buffer history, then fontification
depends on recent buffer history. That's non-determinism. I think it
ought to be obvious why we want to highlight the same characters with
the same faces no matter how those characters came to be in the buffer.

>> 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!

The mode can start analyzing wherever it wants. There is no rule saying
that a mode's font-locking functions can't look at buffer positions
before `beg'. font-lock is telling you were it wants you to apply
fontification. You can go back further than that to analyze.

This analysis does not requiring that we forbid font-lock from
arbitrarily extending the region. Why can't cc-mode figure out a
"neutral syntactic position" before an arbitrary point?

>> You need better cache invalidation.
> 
> When, where, of what?

Whatever you're trying to achieve by constricting the font-lock region,
you can achieve equally well by maintaining the right caches of buffer
context and consulting these caches when servicing font-lock
fontification requests.

>> 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.

Like I said, the mode can analyze whatever buffer text it wants. Why
does the analysis region (which is implicit in program logic) depend on
the font-lock region?

>> 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.

Why?


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