GNU bug report logs -
#11447
24.1.50; notifications-notify eats keystrokes
Previous Next
Reported by: Peter Münster <pmlists <at> free.fr>
Date: Thu, 10 May 2012 20:46:01 UTC
Severity: normal
Found in version 24.1.50
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
This bug report was last modified 13 years and 61 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.