Re: jit-lock-antiblink-grace

[João Távora]

Eli Zaretskii <address@hidden> writes:

>> From: João Távora <address@hidden>
>> Date: Sat, 30 Nov 2019 20:19:35 +0000
>> Cc: Stefan Monnier <address@hidden>, emacs-devel <address@hidden>, 
>>      Alan Mackenzie <address@hidden>
>> 
>> > > > So how is this a problem, if at worst we get the old behavior?
>> > >
>> > > After b), you now have to wait 2 seconds (jit-lock-antiblink-grace)
>> > > before you get the old behaviour (string-fontifying 7-10).
>> >
>> > Isn't this the new behavior?
>> 
>> Yes, but in this very particular case, it doesn't gain you anything,
>> IMO.
>
> But you don't lose anything, either, right?

Depends on how you look at it.  Let me try to explain.

jit-lock-antiblink-grace is based on presumptions, the main one being
that when you open a string, no two seconds of idle time will elapse
before you close it.  The presumption is also that you will close it
in a further position of the buffer.

In the edge case I described, that doesn't hold: the user wants to close
the string in a previous position.  So I speculate that that user is
accustomed to the old behaviour and will find it odd that the invalid
fontification -- which he/she expects and potentially even likes and
which used to come almost immediately -- now only comes after two
seconds, or when moving up the line.

This is fundamentally different from the main use case of
jit-lock-antiblink, where we are certain that near-immediate invalid
fontification will annoy the user, who we presume will "soon" close the
string.  So delaying that annoying thing is a good decision.

I only mentioned this edge case (which doesn't affect me, personally)
because previously I had written I could not find any useful behaviour
lost by jit-lock-antiblink.  I am doing this for completeness because we
know changing any default is potentially controversial (cue
https://xkcd.com/1172/).

João