bug#11447: 24.1.50; notifications-notify eats keystrokes

[Michael Albinus <michael.albinus@gmx.de>]

Stefan Monnier <monnier@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.