[Top][All Lists]

[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: Mon, 25 Nov 2019 21:07:05 +0000

On Mon, Nov 25, 2019 at 8:23 PM João Távora <address@hidden> wrote:
> On Mon, Nov 25, 2019 at 8:11 PM Alan Mackenzie <address@hidden> wrote:
> > For me, at least, point 1 doesn't hold.  Having the fontification
> > delayed until 2 seconds of inactivity would for me be intensely
> > irritating.
> This is not how it works. The only thing that is delayed is
> guaranteed to be unwanted, namely, fontifying as string
> a big chunk of the buffer that we know wasn't a string
> before the user opened a string.

Actually, let me clarify this "guaranteed to be unwanted".
The "unwanted" fontification of the large part of the buffer is
guaranteed never to be fully correct, I think.  But some of
it _might_ be correct, and, as such, helpful, namely when
you really want to define a multi-line string by first entering
the quote, thus unbalancing the whole buffer (and incorrectly
fontifying a part of it), paging down some lines, and then
rebalancing it by entering another quote.

(If it weren't so, we could downright abolish the behaviour,
equivalent to setting jit-lock-antiblink-grace to infinity.)

But even in that particular case, whose frequency I presume to
be minute in proportion to the number of opened-and-closed
strings, it can be argued that the patch has a benefit,
since it's normally easier to spot where you want to end the
new string made of existing non-string text when it's fontified
as non-string text.  The amount of CPU spent is also lower.

João Távora

reply via email to

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