From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Harald Hanche-Olsen <hanche@math.ntnu.no>
Cc: borja.tarraso.hueso@googlemail.com, emacs-devel@gnu.org
Subject: Re: Possible emacs bug when type password fields
Date: Fri, 01 May 2009 15:57:32 -0400 [thread overview]
Message-ID: <jwv4ow4y4yl.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20090501.184211.227773522.hanche@math.ntnu.no> (Harald Hanche-Olsen's message of "Fri, 01 May 2009 18:42:11 +0200 (CEST)")
>> I was wondering if this is a known issue or not, but it seems some emacs
>> bug, when I tried M-x gnus or M-x erc or any other feature in emacs (it
>> means that is not emacs specific feature bug) I cannot use num keypad to
>> type the password field. I tried in two different computers, with two
>> different emacs versions, and different features, with same results.
Can you try the patch below? I don't have any keyboard with a numeric
keypad any more ;-)
Note that this patch is not acceptable for Emacs-23.1 (which is now
too far in the pretest phase for such a change).
Stefan
--- subr.el.~1.636.~ 2009-04-20 12:12:55.000000000 -0400
+++ subr.el 2009-05-01 15:52:48.000000000 -0400
@@ -1728,6 +1728,47 @@
\f
;;;; Input and display facilities.
+(defconst read-key-empty-map (make-sparse-keymap))
+(defvar read-key-delay 0.1)
+
+(defun read-key (&optional prompt)
+ "Read a key from the keyboard.
+Contrary to `read-event' this will not return a raw event but instead will
+obey the input decoding and translations usually done by `read-key-sequence'.
+So escape sequences and keyboard encoding are taken into account.
+When there's an ambiguity because the key looks like the prefix of
+some sort of escape sequence, the ambiguity is resolved via `read-key-delay'."
+ (let ((overriding-terminal-local-map read-key-empty-map)
+ (overriding-local-map nil)
+ (old-global-map (current-global-map))
+ (timer (run-with-idle-timer
+ ;; Wait long enough that Emacs has the time to receive and
+ ;; process all the raw events associated with the single-key.
+ ;; But don't wait too long, or the user may find the delay
+ ;; annoying (or keep hitting more keys which may then get
+ ;; lost or misinterpreted).
+ ;; This is only relevant for keys which Emacs perceives as
+ ;; "prefixes", such as C-x (because of the C-x 8 map in
+ ;; key-translate-table and the C-x @ map in function-key-map)
+ ;; or ESC (because of terminal escape sequences in
+ ;; input-decode-map).
+ read-key-delay t
+ (lambda ()
+ (let ((keys (this-command-keys-vector)))
+ (unless (zerop (length keys))
+ ;; `keys' is non-empty, so the user has hit at least
+ ;; one key; there's no point waiting any longer, even
+ ;; though read-key-sequence thinks we should wait
+ ;; for more input to decide how to interpret the
+ ;; current input.
+ (throw 'read-key keys)))))))
+ (unwind-protect
+ (progn
+ (use-global-map read-key-empty-map)
+ (aref (catch 'read-key (read-key-sequence prompt nil t)) 0))
+ (cancel-timer timer)
+ (use-global-map old-global-map))))
+
(defvar read-quoted-char-radix 8
"*Radix for \\[quoted-insert] and other uses of `read-quoted-char'.
Legitimate radix values are 8, 10 and 16.")
@@ -1844,10 +1885,7 @@
(while (progn (message "%s%s"
prompt
(make-string (length pass) ?.))
- ;; We used to use read-char-exclusive, but that
- ;; gives funny behavior when the user presses,
- ;; e.g., the arrow keys.
- (setq c (read-event nil t))
+ (setq c (read-key))
(not (memq c stop-keys)))
(clear-this-command-keys)
(cond ((memq c rubout-keys) ; rubout
next prev parent reply other threads:[~2009-05-01 19:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-01 11:13 Possible emacs bug when type password fields Borja Tarraso Hueso
2009-05-01 16:42 ` Harald Hanche-Olsen
2009-05-01 19:57 ` Stefan Monnier [this message]
2009-05-01 21:28 ` Harald Hanche-Olsen
2009-05-05 18:36 ` Borja Tarraso
2009-05-06 1:21 ` Stefan Monnier
2009-05-06 8:57 ` Andreas Schwab
2009-05-06 14:25 ` Stefan Monnier
2009-05-06 15:08 ` Harald Hanche-Olsen
2009-05-06 15:08 ` Andreas Schwab
2009-05-06 18:58 ` Stefan Monnier
2009-05-07 20:53 ` Borja Tarraso
2009-05-08 1:01 ` Stefan Monnier
2009-05-14 0:35 ` Borja Tarraso
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=jwv4ow4y4yl.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=borja.tarraso.hueso@googlemail.com \
--cc=emacs-devel@gnu.org \
--cc=hanche@math.ntnu.no \
/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.