GNU bug report logs - #11447
24.1.50; notifications-notify eats keystrokes

Previous Next

Full log

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Peter Münster <pmlists <at> free.fr>, 11447 <at> debbugs.gnu.org
Subject: Re: bug#11447: 24.1.50; notifications-notify eats keystrokes
Date: Fri, 11 May 2012 17:27:54 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Maybe, but I don't know how. I've tried this:
>
>>     (with-timeout ((if timeout (/ timeout 1000.0) 25))
>>       (while (eq (gethash key dbus-return-values-table :ignore) :ignore)
>>       (or (input-pending-p) (sit-for 0.1 'nodisp))))
>
> Well, actually if you use sit-for you don't need input-pending-p.

OK.

>> With the example in this bug report, I get blocked then.
>
> What do you mean by "blocked"?

An input char goes into unread-command-event. Since nobody handles it,
the while-loop runs forever.

>> A key might be placed in `unread-command-events', and I still must
>> handle it.
>
> What do you mean by "handle it"?

The char event shall be taken from unread-command-event, and (for
example) inserted into the current buffer.

> Could let-binding unread-command-events around the call to sit-for
> address the issue?

Then we have the initial situation, as reported by Peter. The char is
put into the let-bound unread-command-events, and it is lost when the
let-clause ends.

I simply don't know, who shall be responsible to move an event from
unread-command-events. In the example I've shown above, it is not done.

>         Stefan

Best regards, Michael.

Previous Next

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