Subject: RE: bug#5923: 23.1.95; minibuffer-message discards input events

From: "Drew Adams" <[email-masked]>
Date: Tue, 20 Apr 2010 09:18:28 -0700

The problem appears to be with `sit-for', not with `minibuffer-message'. More
specifically, the call to `input-pending-p' in `sit-for' does not act as it
should. Dunno if `input-pending-p' is the problem generally, or just in this
context.

Attached is a small, simple, self-contained file that reproduces the problem.
Just load it, then `M-x C-u sssss'. The `s' keystrokes are ignored while the
`sit-for' delay is waited for.

In all cases except `icicle-universal-argument', the original command is called,
followed by a call to `message' and then `sit-for'.

`icicle-universal-argument' is identical to `universal-argument' except:

* It too calls `message' followed by `sit-for'.
* It uses `icicle-ensure-overriding-map-is-bound', not
`ensure-overriding-map-is-bound'. The difference is that the former sets
`overriding-terminal-local-map' to `icicle-universal-argument-map', not
`universal-argument-map'.

The difference between those two maps is that the `icicle-*' commands are used
in place of the originals (and each `icicle-*' command calls `message' followed
by `sit-for').

So all of the changes from the vanilla Emacs code amount to the same trivial
change: Add a call to `message' and `sit-for' after the vanilla command behavior
is finished. There are no other changes.

`sit-for' seems to be the problem, but there is no change in the code for
`sit-for' from Emacs 22 and Emacs 23 (where the bug first appears). Perhaps
there is a relevant change elsewhere that has to do with these keymaps or with
input events? 

Debugging `sit-for' a bit indicates that `input-pending-p' does indeed return
nil when it should return non-nil in this context (after user input). The final
`cond' branch is taken in the `sit-for' code, instead of the `input-pending-p'
branch.

There is no change in the C source code for `input-pending-p' itself, between
Emacs 22 and 23. But it tests several global vars in order to do its thing, so
perhaps the bug was introduced by changing the value of one of those vars. The
vars are `unread-command-events', `unread-command-char',
`unread-post-input-method-events', and `unread-input-method-events'. That seems
likely.

Note this in the doc string of `input-pending-p': "Actually, the value is nil
only if we can be ***sure*** that no input is available; if there is a doubt,
the value is t."

Obviously, we are by no means respecting that declared conservative behavior. It
is returning nil (in this case) even when we should not be sure that no input is
available - even when input is in fact available.

I hope this bug will be fixed. Thx.