Re: Possible emacs bug when type password fields

[Borja Tarraso <borja.tarraso.hueso@googlemail.com>]

Hi Stefan,

Sorry for late reply. I patched using your diffs, and it works, however
i seen new issues, e.g. when I press C-g in this input password is
not cancelling this command and writes some additional characters
to the password field.

Thanks!

Borja Tarraso

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

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