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

["Drew Adams" <drew.adams@oracle.com>]

> 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.

Actually, the problem is here in `sit-for':

(let ((read (read-event nil nil seconds)))
      (or (null read)
	  (progn
	    ;; If last command was a prefix arg, e.g. C-u, push this event onto
	    ;; unread-command-events as (t . EVENT) so it will be added to
	    ;; this-command-keys by read-key-sequence.
	    (if (eq overriding-terminal-local-map universal-argument-map)
		(setq read (cons t read)))
	    (push read unread-command-events)
	    nil))))))

Since the value of `overriding-terminal-local-map' is not
`universal-argument-map' in my case, it fails to treat any input received
properly.

Since this needs to span several commands (digit-argument etc.), I can't just
bind `overriding-terminal-local-map' instead of setting it. I guess my options
are to either set it to my map and later unset it or just redefine `sit-for' so
that it uses a test like this instead:

(if (memq overriding-terminal-local-map
          '(universal-argument-map icicle-universal-argument-map))
    (setq read (cons t read)))

Or redefine `universal-argument-map' to use commands that act differently
depending on the mode etc.

Better suggestions are welcome. None that I've thought of so far are appealing.

How about using a different kind of test in the vanilla code, one that would
give users some flexibility here, instead of hard-coding an eq test against a
specific keymap?