bug#22714: 25.0.91; Minibuffer quirk in C-x r SPC

bug#22714: 25.0.91; Minibuffer quirk in C-x r SPC

[Steve Revilak]

[-- Attachment #1: Type: text/plain, Size: 3534 bytes --]

Steps to reproduce:

  1. emacs -Q.  This starts emacs, and shows the default *scratch* buffer
  2. put point on line 2, column 0
  3. Press "C-x r SPC"
  4. The minibuffer prompts "Point to Register: "
  5. Press "1"

Expected Behavior:

After pressing "1", I'd expect the minibuffer's "Point to Register: "
prompt to disappear.


Actual Behavior:

The minibuffer continues to display "Point to Register: 1", as if it's
waiting for me to provide additional input.  At this point, I'd
typically press the UP or DOWN arrows no my keyboard, to dismiss the
minibuffer prompt.

Pressing RET while "Point to Register: 1" appears in the minibuffer
causes a RET to be inserted into the buffer that was active when "C-x r
SPC" was pressed.


Regression Notes:

I first observed this behavior in emacs 25.0.90.  I did not observe it
in earlier versions (e.g., 24.x).




In GNU Emacs 25.0.91.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.15)
  of 2016-02-16 built on sunny
Windowing system distributor 'The X.Org Foundation', version 11.0.11601000
System Description:	openSUSE 13.2 (Harlequin) (x86_64)

Configured using:
  'configure --prefix=/usr/local/emacs-25.0.91'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
ACL GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
   value of $LC_COLLATE: C
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec epg epg-config gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util help-fns help-mode easymenu cl-loaddefs pcase
cl-lib mail-prsvr mail-utils time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 87263 9234)
  (symbols 48 19682 0)
  (miscs 40 40 135)
  (strings 32 14739 4264)
  (string-bytes 1 422275)
  (vectors 16 12268)
  (vector-slots 8 425296 4875)
  (floats 8 167 180)
  (intervals 56 200 0)
  (buffers 976 11)
  (heap 1024 47551 1058))

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#22714: 25.0.91; Minibuffer quirk in C-x r SPC

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

I don't have a solution but I can confirm this behavior.

In emacs 24.5, the "Point to Register" prompt disappears after pressing "1".
In emacs 25.x, the prompt stays there after pressing "1".

I tried edebugging in both 24.5 and 25.x but the behavior looks the same
when doing edebug (the prompt disappears).

I briefly looked at the register.el, but couldn't spot any change there
that could be causing this. So the change is probably in some common
library in elisp/C.

--
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 666 bytes --]

bug#22714: 25.0.91; Minibuffer quirk in C-x r SPC

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

OK, I found the change that caused this.

http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25&id=0da7d35c6754b44d1ef4383e4a8ba9b98afc3a4c

diff --git a/lisp/register.el b/lisp/register.el
index 1c64a9a..6a5792c 100644
--- a/lisp/register.el
<http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/register.el?h=emacs-25&id=c435f506a1fd8fbf2bd22f59226ef296a3eb6ab3>
+++ b/lisp/register.el
<http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/register.el?h=emacs-25&id=0da7d35c6754b44d1ef4383e4a8ba9b98afc3a4c>
@@ -161,7 +161,7 @@ display such a window regardless."
collect c)))
(unwind-protect
(progn
- (while (memq (read-event (propertize prompt 'face 'minibuffer-prompt))
+ (while (memq (read-key (propertize prompt 'face 'minibuffer-prompt))
help-chars)
(unless (get-buffer-window buffer)
(register-preview buffer 'show-empty)))

It's the use of read-key instead of read-event that's causing this.

Stefan should be able to comment more on why that changes the behavior of
the prompt staying vs disappearing.


--
Kaushal Modi

On Wed, Feb 17, 2016 at 8:56 AM, Kaushal Modi <kaushal.modi@gmail.com>
wrote:

>
> I don't have a solution but I can confirm this behavior.
>
> In emacs 24.5, the "Point to Register" prompt disappears after pressing
> "1".
> In emacs 25.x, the prompt stays there after pressing "1".
>
> I tried edebugging in both 24.5 and 25.x but the behavior looks the same
> when doing edebug (the prompt disappears).
>
> I briefly looked at the register.el, but couldn't spot any change there
> that could be causing this. So the change is probably in some common
> library in elisp/C.
>
> --
> Kaushal Modi
>

[-- Attachment #2: Type: text/html, Size: 4067 bytes --]

bug#22714: 25.0.91; Minibuffer quirk in C-x r SPC

[Stefan Monnier]

> Stefan should be able to comment more on why that changes the behavior of
> the prompt staying vs disappearing.

Good question.  `read-key' uses `read-key-sequence' internally, and this
function has always left the prompt on display.

Maybe read-key should be changed to behave more like read-event (and
read-char), since it's typically used in the same kinds of situations.

IOW, we should probably install one of the two patches below.


        Stefan


diff --git a/lisp/subr.el b/lisp/subr.el
index 7478595..cd1b945 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -2116,6 +2116,10 @@ some sort of escape sequence, the ambiguity is resolved via `read-key-delay'."
                 (aref keys 1)
               key)))
       (cancel-timer timer)
+      ;; For some reason, `read-key(-sequence)' leaves the prompt in the echo
+      ;; area, whereas `read-event' seems to empty it just before returning
+      ;; (bug#22714).  So, let's mimick the behavior of `read-event'.
+      (message nil)
       (use-global-map old-global-map))))
 
 (defun read-char (&optional prompt) ;; (inherit-input-method seconds)



diff --git a/lisp/register.el b/lisp/register.el
index faed49a..5fab2b0 100644
--- a/lisp/register.el
+++ b/lisp/register.el
@@ -164,6 +164,13 @@ display such a window regardless."
 		       help-chars)
 	    (unless (get-buffer-window buffer)
 	      (register-preview buffer 'show-empty)))
+          ;; FIXME: For some reason, `read-key(-sequence)' leaves the prompt in
+          ;; the echo area, contrary to `read-event' which seems to empty it
+          ;; just before returning (bug#22714).
+          ;; Not sure what's the best fix: maybe read-key should be changed to
+          ;; behave like read-event.  But in the mean time, the hack below
+          ;; should work.
+          (message nil)
 	  (if (characterp last-input-event) last-input-event
 	    (error "Non-character input-event")))
       (and (timerp timer) (cancel-timer timer))

bug#22714: 25.0.91; Minibuffer quirk in C-x r SPC

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 2298 bytes --]

Hi Stefan,

I am not a good judge for this. Can you please commit the fix that feels
the most right?

On Sat, Feb 20, 2016 at 3:32 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > Stefan should be able to comment more on why that changes the behavior of
> > the prompt staying vs disappearing.
>
> Good question.  `read-key' uses `read-key-sequence' internally, and this
> function has always left the prompt on display.
>
> Maybe read-key should be changed to behave more like read-event (and
> read-char), since it's typically used in the same kinds of situations.
>
> IOW, we should probably install one of the two patches below.
>
>
>         Stefan
>
>
> diff --git a/lisp/subr.el b/lisp/subr.el
> index 7478595..cd1b945 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -2116,6 +2116,10 @@ some sort of escape sequence, the ambiguity is
> resolved via `read-key-delay'."
>                  (aref keys 1)
>                key)))
>        (cancel-timer timer)
> +      ;; For some reason, `read-key(-sequence)' leaves the prompt in the
> echo
> +      ;; area, whereas `read-event' seems to empty it just before
> returning
> +      ;; (bug#22714).  So, let's mimick the behavior of `read-event'.
> +      (message nil)
>        (use-global-map old-global-map))))
>
>  (defun read-char (&optional prompt) ;; (inherit-input-method seconds)
>
>
>
> diff --git a/lisp/register.el b/lisp/register.el
> index faed49a..5fab2b0 100644
> --- a/lisp/register.el
> +++ b/lisp/register.el
> @@ -164,6 +164,13 @@ display such a window regardless."
>                        help-chars)
>             (unless (get-buffer-window buffer)
>               (register-preview buffer 'show-empty)))
> +          ;; FIXME: For some reason, `read-key(-sequence)' leaves the
> prompt in
> +          ;; the echo area, contrary to `read-event' which seems to empty
> it
> +          ;; just before returning (bug#22714).
> +          ;; Not sure what's the best fix: maybe read-key should be
> changed to
> +          ;; behave like read-event.  But in the mean time, the hack below
> +          ;; should work.
> +          (message nil)
>           (if (characterp last-input-event) last-input-event
>             (error "Non-character input-event")))
>        (and (timerp timer) (cancel-timer timer))
>

[-- Attachment #2: Type: text/html, Size: 2916 bytes --]

bug#22714: 25.0.91; Minibuffer quirk in C-x r SPC

[Stefan Monnier]

> I am not a good judge for this. Can you please commit the fix that feels
> the most right?

Sure, done,


        Stefan

bug#22714: 25.0.91; Minibuffer quirk in C-x r SPC

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 226 bytes --]

Thanks!

On Fri, Apr 8, 2016 at 2:02 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > I am not a good judge for this. Can you please commit the fix that feels
> > the most right?
>
> Sure, done,
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 506 bytes --]