Re: Possible emacs bug when type password fields

[Stefan Monnier]

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