bug#23980: 25.0.95; Events put in `unread-command-events' can be wrongly handled

[Dmitry Gutov <dgutov@yandex.ru>]

On 2/21/18 9:40 AM, Chris Feng wrote:

> It seems to be the only use case in Emacs's source tree, but we can't
> tell how many packages do this trick in the wild nor can we predict
> that.

They only do that with one goal, though (so we are dealing with a protocol).

>> But then how come you have (t t . 45) there?
> 
> Probably shortly after (t . 45) is unread another call to `sit-for'
> happens to read it out directly from `unread-command-events', and the
> event is further unread as (cons t '(t . 45)).

More or less, this. Except we don't get this effect from two (or more) 
consecutive calls to sit-for.

What triggers it, is effectively recursive sit-for calls, when the 
second sit-for is called inside a timer, which are allowed to run inside 
the first sit-for.

> PS. Many users will stick with the pre-26 releases in the next upcoming
> years so backporting this fix does not necessarily resolve the problem
> for company-mode.  At least a workaround has to be come up with to deal
> with the situations where this fix is absent.

I've been trying to. So far, the options are:

- Advise users to lower flyspell-delay to (* 0.9 company-idle-delay). 
That actually leads to freezes, which I should file as a separate bug 
report.

- Ask people to disable flyspell-mode :)

- Use sleep-for instead of sit-for in the relevant place, forgoing the 
significant latency improvement that comes with the latter. Maybe 
predicated on Emacs version, and flyspell-mode being enabled.

So far the last option is winning, but I'd be much more content to use 
it if the Emacs 26 are not going to need it.