GNU bug report logs - #3287
GNU/Emacs bug when typed in prompt password fields using keypad

Previous Next

Package: emacs;

Reported by: Borja Tarraso Hueso <borja.tarraso.hueso <at> googlemail.com>

Date: Thu, 14 May 2009 16:00:05 UTC

Severity: normal

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3287 in the body.
You can then email your comments to 3287 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>:
bug#3287; Package emacs. (Thu, 14 May 2009 16:00:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Borja Tarraso Hueso <borja.tarraso.hueso <at> googlemail.com>:
New bug report received and forwarded. Copy sent to Emacs Bugs <bug-gnu-emacs <at> gnu.org>. (Thu, 14 May 2009 16:00:06 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Borja Tarraso Hueso <borja.tarraso.hueso <at> googlemail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: monnier <at> iro.umontreal.ca
Subject: GNU/Emacs bug when typed in prompt password fields using keypad
Date: Thu, 14 May 2009 16:52:51 +0100
[Message part 1 (text/plain, inline)]
Hi people,

I just found a bug when is used keypad under password input field in emacs,
that's not doing anything, so these diffs provided by Stefan and slightly
modified by us, to handle C-g case, fix the problem<monnier <at> iro.umontreal.ca>
.

==> Bug:

Under GNU/Linux trying to write numbers using keypad in a prompt input
password field does not works. This is not happening under Windows OS. Not
other OS tested.

This is reproducible in any gnu/emacs version from cvs (e.g. 23.0.90.2).

==> Fix:

Usage of read-key instead read-event. As read-key is getting each key but
not inserted and handled until pressed return, so we should take care about
C-g case as well to provide user's cancellation.

==> Diffs:

*** emacs/lisp/subr.el  2009-02-14 09:06:56.000000000 +0000
--- emacs_hack/lisp/subr.el     2009-05-14 01:29:52.000000000 +0100
***************
*** 1721,1726 ****
--- 1721,1767 ----
- Mostrar texto citado -


 ;;;; 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.")
***************
*** 1837,1846 ****
        (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))
                      (not (memq c stop-keys)))
         (clear-this-command-keys)
         (cond ((memq c rubout-keys) ; rubout
--- 1878,1884 ----
        (while (progn (message "%s%s"
                              prompt
                              (make-string (length pass) ?.))
!                     (setq c (read-key))
                      (not (memq c stop-keys)))
         (clear-this-command-keys)
         (cond ((memq c rubout-keys) ; rubout
***************
*** 1848,1855 ****
                  (let ((new-pass (substring pass 0 -1)))
                     (and (arrayp pass) (clear-string pass))
                    (setq pass new-pass))))
               ((not (numberp c)))
!               ((= c ?\C-u) ; kill line
                (and (arrayp pass) (clear-string pass))
                 (setq pass ""))
               ((= c ?\C-y) ; yank
--- 1886,1895 ----
                  (let ((new-pass (substring pass 0 -1)))
                     (and (arrayp pass) (clear-string pass))
                    (setq pass new-pass))))
+               ((eq c ?\C-g)
+                (keyboard-quit))
               ((not (numberp c)))
!               ((eq c ?\C-u) ; kill line
                 (and (arrayp pass) (clear-string pass))
                 (setq pass ""))
               ((= c ?\C-y) ; yank


==> End.

Thanks!

Borja Tarraso
[Message part 2 (text/html, inline)]

Reply sent to Stefan Monnier <monnier <at> iro.umontreal.ca>:
You have taken responsibility. (Thu, 20 Aug 2009 20:02:37 GMT) Full text and rfc822 format available.

Notification sent to Borja Tarraso Hueso <borja.tarraso.hueso <at> googlemail.com>:
bug acknowledged by developer. (Thu, 20 Aug 2009 20:02:38 GMT) Full text and rfc822 format available.

Message #10 received at 3287-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Borja Tarraso Hueso <borja.tarraso.hueso <at> googlemail.com>
Subject: Re: GNU/Emacs bug when typed in prompt password fields using keypad
Date: Wed, 19 Aug 2009 15:48:07 -0400
I've just installed a patch that uses read-key into the CVS trunk.
So, I believe the problem is now fixed,


        Stefan



bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> emacsbugs.donarmstrong.com. (Fri, 18 Sep 2009 14:24:17 GMT) Full text and rfc822 format available.

This bug report was last modified 15 years and 277 days ago.

Previous Next


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