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

[Chris Feng <chris.w.feng@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> On 2/20/18 8:37 PM, Eli Zaretskii wrote:
>>
>> > I'd need someone (Chris?) to tell which situations cause (t SOMETHING)
>> > be put into unread-command-events.  If these situations are rare
>> > enough, maybe we can risk it.
>>
>> At least one of the places that do that is sit-for. See the long comment
>> at the end of its definition (I don't really understand its last
>> sentence, FWIW).

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.

> 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)).  Perhaps we may even get
something like (t t t . 45) if lucky enough.

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.