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

Previous Next

Full log

Message #29 received at 23980 <at> debbugs.gnu.org (full text, mbox):

From: Chris Feng <chris.w.feng <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23980 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#23980: 25.0.95;
 Events put in `unread-command-events' can be wrongly handled
Date: Wed, 21 Feb 2018 15:40:35 +0800

Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.