Re: jit-lock-antiblink-grace

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: João Távora <joaotavora@gmail.com>,
>   emacs-devel@gnu.org
> Date: Sat, 12 Oct 2019 10:13:42 -0400
> 
> > We also have display-related hooks.  If you could use one of them,
> > that might be better, because one could generally type quite a few
> > commands before redisplay kicks in, and post-command-hook runs once
> > for every command.
> 
> Really?  AFAIK we redisplay at the end of every command executed.

No, we do that only if there's no other event in the event queue.

> We additionally redisplay after processing filters and after receiving
> an event that turned out to be a prefix key, etc...

Filters run only when Emacs is idle, so they don't run when there are
keyboard events in the queue.

> So, AFAICT we generally redisplay at least as often as we run
> post-command-hook.

I don't think this is correct, not AFAIR.

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

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

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

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