[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
Subject: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Tue, 20 Apr 2010 16:45:45 -0700

> 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)
            ;; 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)

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

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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]