GNU bug report logs - #5923
23.1.95; minibuffer-message discards input events

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Sat, 10 Apr 2010 16:55:02 UTC

Severity: normal

Tags: fixed

Merged with 3938

Done: npostavs <at> users.sourceforge.net

Bug is archived. No further changes may be made.

Full log


Message #29 received at 5923 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 5923 <at> debbugs.gnu.org
Subject: RE: 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)
	  (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?





This bug report was last modified 8 years and 295 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.