Re: jit-lock-antiblink-grace

[Stefan Monnier]

>> The only case where we don't is when we can't keep up with the input
>> events in which case we skip redisplay, but that's the case where
>> we're *already* too slow.
>
> My point is that post-command-hook might be called more often than
> once per redisplay cycle, and I think we agree on that, right?

Yes, but only if we can't keep up (i.e. if the event queue is already
non-empty when we're done processing an event).  So whether something is
done in redisplay or in post-command-hook doesn't affect the repeat-rate
threshold where we start skipping redisplay: it only affect how much
speed we gain by skipping redisplay (i.e. how quickly we can recover).

>> > It's a backward-incompatible behavior, and is not being developed due
>> > to bug reports,
>> It was developed because people like Alan are so bothered by the
>> flashing that they're going through lengths to find other ways to
>> avoid it.
> I'm not saying this is not a useful feature, and I'm not objecting to
> its inclusion.  I'm asking why do we need to turn it on by default
> right when we introduce it.

Because I think it offers the behavior 99% of the users will want
(modulo bugs).  Everyone I ever talked to about this agreed that the
current behavior is somewhat annoying and several of them mentioned
using "strategies" to avoid it (e.g. use electric-pair-mode, or be sure
to keep typing quickly so the string/comment gets closed before the
jit-lock-context-timer fires, ...).

>> > so why make it the default right from the start?  It also slows down
>> > cursor motion (which should probably be in the doc string as well).
>> It shouldn't slow down cursor motion, normally (at least not in any
>> measurable way).
> Font lock does slow down Emacs, so calling it in more cases/places
> will do so as well.

AFAICT the code doesn't call font-lock.

>> > I still don't think I understand what would constitute an
>> > "unterminated string at EOL", then.  Could you show two examples, one
>> > where there is such a string, the other where there isn't?
>> 
>> Code like:
>> 
>>     var x = "foo y = "bar";
>> 
>> where the user is in the middle of writing `x = "foobar";` but hasn't yet
>> closed the string.
>
> Yes, and what is the other example I asked for, where we don't have an
> unterminated string at EOL due to such editing?

That would be "any normal line", as in:

    var x = "foobar"; y = "bar";

"unterminated string at EOL" means (nth 3 (syntax-ppss
(line-end-position))) is non-nil.


        Stefan