emacs-devel
[Top][All Lists]
Advanced

[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 20:12:51 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>>     between line 3 and 7.
>> b.  You go to line 7 and type a quote
>> c.  You go to line 3 and type a quote
>> 
>> Previously, after step b) you would get lines 8, 9, and 10 (and 7
>> partially) string-fontified "immediately".
>> 
>> Now, after step b), and _if stay on the same line_, it takes 2 seconds
>> for lines 7-10 to be string-fontified.  If you leave line 7 in your
>> journey to line 3 before those 2 seconds are up, 7-10 are immediately
>> string-fontified (and the old and new version become identical in
>> behaviour).
>
> 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).  Previously,
you would get it after 0.5 seconds (jit-lock-context-time).  It's
arguable that the new behaviour is worse than the old one, for the
specific case where you already expected lines 7-10 to be temporarily
invalidly fontified anyway. (I say "invalid" because the user's
intention is to move up to line 3)

Anyway, I think it's a pretty minor thing, but I wanted to record it for
completeness.

>> +** New customizable variable 'jit-lock-antiblink-grace'.
>> +When typing strings, this helps avoid "blinking", an oscillation
>> +between string and non-string fontification.  The variable holds a
>> +number of seconds (default is 2) before a potentially unwanted
>> +fontification starts.  Set to nil to deactivate.
>                           ^^^^^^^^^^^^^^^^^^^^^^^^
> "Deactivate" is not self-explanatory here, because the text didn't
> mention any "activation".  I suggest this instead:
>
>   Set to nil to get back the old behavior.

OK.

I will also add the "set marker buffer to nil" optimization that Alan
suggested.

If there's no further comments, I will push this to master in a day or
so.

João





reply via email to

[Prev in Thread] Current Thread [Next in Thread]