Re: jit-lock-antiblink-grace

[Stefan Monnier]

>> My very first version relied on an extension of the existing
>> jit-lock-context-time, but I seem to remember it broke down here and
>> there sometimes.  I agreed with Stefan (possibly off-list) to use a
>> post-command-hook, which is safer.  But I can have a look at the

[ FWIW: I can't remember why I recommended/suggested
  post-command-hook, sorry.  ]

>> original version and re-study those problems more closely.
> 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.
We additionally redisplay after processing filters and after receiving
an event that turned out to be a prefix key, etc...

So, AFAICT we generally redisplay at least as often as we run
post-command-hook.  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.

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

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

Also I expect the implementation will change over time, as experience is
gained with it.

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


        Stefan