From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 5923@debbugs.gnu.org
Subject: bug#5923: 23.1.95; minibuffer-message discards input events
Date: Tue, 20 Apr 2010 16:45:45 -0700 [thread overview]
Message-ID: <45AB7455D0FD4FCC9ED735A11D8CCEF0@us.oracle.com> (raw)
In-Reply-To: <C68D354839BC439681CDDE4359E56473@us.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?
next prev parent reply other threads:[~2010-04-20 23:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-10 16:52 bug#5923: 23.1.95; minibuffer-message discards input events Drew Adams
2010-04-10 19:15 ` Stefan Monnier
2010-04-10 19:59 ` Drew Adams
2010-04-14 2:19 ` Stefan Monnier
2010-04-14 5:06 ` Drew Adams
2010-04-19 5:38 ` Drew Adams
2010-04-19 6:09 ` Drew Adams
2010-04-20 16:18 ` Drew Adams
2010-04-20 23:45 ` Drew Adams [this message]
2010-04-21 0:05 ` Drew Adams
2010-07-23 22:26 ` Stefan Monnier
2010-07-28 15:24 ` Drew Adams
2016-07-05 4:06 ` npostavs
2016-07-05 14:19 ` Drew Adams
2016-07-06 13:11 ` Noam Postavsky
2016-07-06 13:59 ` Drew Adams
2016-07-06 14:55 ` Noam Postavsky
2016-07-06 15:05 ` Eli Zaretskii
2016-07-06 15:30 ` Noam Postavsky
2016-07-06 15:38 ` Eli Zaretskii
2016-07-06 14:25 ` bug#3938: " Eli Zaretskii
2016-07-06 15:10 ` bug#5923: " Drew Adams
2016-07-06 15:32 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45AB7455D0FD4FCC9ED735A11D8CCEF0@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=5923@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.