[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: jit-lock-antiblink-grace
From: |
João Távora |
Subject: |
Re: jit-lock-antiblink-grace |
Date: |
Sat, 30 Nov 2019 22:00:24 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
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
- Re: jit-lock-antiblink-grace, (continued)
- Re: jit-lock-antiblink-grace, João Távora, 2019/11/25
- Re: jit-lock-antiblink-grace, João Távora, 2019/11/25
- Re: jit-lock-antiblink-grace, João Távora, 2019/11/25
- Re: jit-lock-antiblink-grace, Eli Zaretskii, 2019/11/26
- Re: jit-lock-antiblink-grace, João Távora, 2019/11/30
- Re: jit-lock-antiblink-grace, Eli Zaretskii, 2019/11/30
- Re: jit-lock-antiblink-grace, João Távora, 2019/11/30
- Re: jit-lock-antiblink-grace, Eli Zaretskii, 2019/11/30
- Re: jit-lock-antiblink-grace, João Távora, 2019/11/30
- Re: jit-lock-antiblink-grace, Eli Zaretskii, 2019/11/30
- Re: jit-lock-antiblink-grace,
João Távora <=
- Re: jit-lock-antiblink-grace, Stefan Monnier, 2019/11/26
- Re: jit-lock-antiblink-grace, Dmitry Gutov, 2019/11/25
- Re: jit-lock-antiblink-grace, João Távora, 2019/11/25