Re: jit-lock-antiblink-grace

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: joaotavora@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 12 Oct 2019 10:34:44 -0400
> 
> >> 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).

What is the purpose of this argument?  Do you agree that adding too
much to post-command-hook should be avoided?  If you do, then let's
not split hair about the rest, okay?

> > 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).

You are entitled to your opinion, and I'm entitled to mine.

> Everyone I ever talked to about this agreed that the current
> behavior is somewhat annoying

Here, you are talking to someone who is much more annoyed by the
sluggishness of our movement commands than by an occasional "flashes"
of incorrect fontification when I'm in the process of modifying code.
So I guess not "everyone" finds this annoying enough.

> > 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.

It adds a timer that does.