GNU bug report logs - #39564
28.0.50; read-key function do not display the prompt if called from read-from-minibuffer

Previous Next

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

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

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; read-key function do not display the prompt if called from
 read-from-minibuffer
Date: Tue, 11 Feb 2020 15:49:41 +0100

read-key function not display the prompt if called from
read-from-minibuffer

In the current emacs master this issue breaks a package like ivy.

This has been discused in: https://github.com/abo-abo/swiper/issues/2444

As a test code provided by the ivy developer Oleh Krehel:

```
(let ((map (make-sparse-keymap)))
  (define-key map (kbd "C-f") (lambda ()
                                (interactive)
                                (message "%S" (read-key "line1\nline2\nline3\nTest2: "))
                                (minibuffer-keyboard-quit)))
  (read-from-minibuffer "Test1: " nil map))
```


In GNU Emacs 28.0.50 (build 22, x86_64-pc-linux-gnu, GTK+ Version 3.24.13, cairo version 1.17.3)
 of 2020-02-07 built on Ergus
Repository revision: 30abcda54e1b0e15fc10b3db1c2b9f89ca521bfa
Repository branch: master
System Description: Arch Linux

Recent messages:
Loading /home/ergo/.emacs.d/custom.el (source)...done
Source file ‘/home/ergo/.emacs.d/elpa/xclip-1.9/xclip.el’ newer than byte-compiled file; using older file
Starting new Ispell process /usr/bin/aspell with default dictionary...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Load time 0.978641

Configured using:
 'configure --prefix=/mnt/casa/install_arch/emacs --with-mailutils'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD
JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_GB.utf8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  counsel-projectile-mode: t
  projectile-mode: t
  counsel-mode: t
  ivy-mode: t
  which-function-mode: t
  electric-pair-mode: t
  highlight-numbers-mode: t
  flyspell-mode: t
  flymake-mode: t
  global-company-mode: t
  company-mode: t
  composable-mark-mode: t
  composable-mode: t
  which-key-mode: t
  winner-mode: t
  xterm-mouse-mode: t
  xclip-mode: t
  show-paren-mode: t
  override-global-mode: t
  minibuffer-depth-indicate-mode: t
  save-place-mode: t
  delete-selection-mode: t
  savehist-mode: t
  global-display-fill-column-indicator-mode: t
  display-fill-column-indicator-mode: t
  global-display-line-numbers-mode: t
  display-line-numbers-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/cmake-mode hides /home/ergo/.emacs.d/elpa/cmake-mode-20190710.1319/cmake-mode
~/gits/emacs-counsel-gtags/counsel-gtags hides /home/ergo/.emacs.d/elpa/counsel-gtags-20200101.1701/counsel-gtags
/usr/share/emacs/site-lisp/notmuch-crypto hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-crypto
/usr/share/emacs/site-lisp/notmuch-compat hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-compat
/usr/share/emacs/site-lisp/notmuch-hello hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-hello
/usr/share/emacs/site-lisp/notmuch hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch
/usr/share/emacs/site-lisp/notmuch-show hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-show
/usr/share/emacs/site-lisp/notmuch-maildir-fcc hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-maildir-fcc
/usr/share/emacs/site-lisp/coolj hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/coolj
/usr/share/emacs/site-lisp/notmuch-draft hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-draft
/usr/share/emacs/site-lisp/notmuch-tree hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-tree
/usr/share/emacs/site-lisp/notmuch-parser hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-parser
/usr/share/emacs/site-lisp/notmuch-lib hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-lib
/usr/share/emacs/site-lisp/notmuch-mua hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-mua
/usr/share/emacs/site-lisp/notmuch-message hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-message
/usr/share/emacs/site-lisp/notmuch-address hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-address
/usr/share/emacs/site-lisp/notmuch-wash hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-wash
/usr/share/emacs/site-lisp/notmuch-tag hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-tag
/usr/share/emacs/site-lisp/notmuch-print hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-print
/usr/share/emacs/site-lisp/notmuch-query hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-query
/usr/share/emacs/site-lisp/notmuch-jump hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-jump
/usr/share/emacs/site-lisp/notmuch-company hides /home/ergo/.emacs.d/elpa/notmuch-20200109.114/notmuch-company

Features:
(shadow sort notmuch-address notmuch-company notmuch-lib notmuch-version
notmuch-compat mm-view mml-smime smime dig mailcap notmuch-parser cl
company-elisp find-func mail-extr emacsbug message rmc puny format-spec
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils ido-completing-read+
memoize minibuf-eldef ido amx s counsel-projectile ibuffer-projectile
projectile grep ibuf-ext ibuffer ibuffer-loaddefs counsel xdg xref
project dired-x dired dired-loaddefs swiper ivy colir color ivy-overlay
time-date term/screen term/xterm xterm which-func imenu elec-pair
highlight-numbers parent-mode flyspell ispell flymake-proc flymake
compile comint ansi-color warnings thingatpt company-keywords
company-gtags company-dabbrev-code company-dabbrev company-files
company-capf company-semantic company-template company-tng company pcase
init composable composable-mark hydra lv cmake-font-lock ein which-key
advice winner ring cc-styles cc-align cc-engine cc-vars cc-defs xt-mouse
xclip paren cus-edit cus-start cus-load wid-edit diminish
use-package-hydra use-package use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode configmail cl-extra help-mode
use-package-ensure use-package-core mb-depth saveplace delsel savehist
display-fill-column-indicator display-line-numbers autorevert filenotify
info ede/auto eieio-base tex-site edmacro kmacro slime-autoloads rx
package easymenu browse-url url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
early-init tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer 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 composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
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 threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 217173 70557)
 (symbols 48 20877 1)
 (strings 32 68737 2253)
 (string-bytes 1 2241052)
 (vectors 16 26004)
 (vector-slots 8 292356 7356)
 (floats 8 175 1042)
 (intervals 56 1240 0)
 (buffers 1000 12))

Message #8 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ergus <spacibba <at> aol.com>
Cc: 39564 <at> debbugs.gnu.org
Subject: Re: bug#39564: 28.0.50;
 read-key function do not display the prompt if called from
 read-from-minibuffer
Date: Tue, 11 Feb 2020 17:50:45 +0200

> Date: Tue, 11 Feb 2020 15:49:41 +0100
> From: Ergus via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> read-key function not display the prompt if called from
> read-from-minibuffer
> 
> In the current emacs master this issue breaks a package like ivy.
> 
> This has been discused in: https://github.com/abo-abo/swiper/issues/2444
> 
> As a test code provided by the ivy developer Oleh Krehel:
> 
> ```
> (let ((map (make-sparse-keymap)))
>    (define-key map (kbd "C-f") (lambda ()
>                                  (interactive)
>                                  (message "%S" (read-key "line1\nline2\nline3\nTest2: "))
>                                  (minibuffer-keyboard-quit)))
>    (read-from-minibuffer "Test1: " nil map))
> ```

I tried this, but without instructions how to reproduce the problem, I
cannot be sure I did the required gestures.  Just evaluating the above
in *scratch* and then typing C-f does show the prompt, IIUC what is
meant by that.

So please provide more detailed instructions to reproduce the issue.

Thanks.

Message #11 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Oleh Krehel <ohwoeowho <at> gmail.com>
To: 39564 <at> debbugs.gnu.org
Subject: Re: bug#39564: 28.0.50; read-key function do not display the prompt
 if called from read-from-minibuffer
Date: Tue, 11 Feb 2020 17:17:02 +0100

Hello,

Here's an updated code that works as intended on 26.3 and unexpected on 28.

(defun make-lines (n)
  (mapconcat #'number-to-string
             (number-sequence 0 n) "\n"))

(let ((map (make-sparse-keymap)))
  (define-key map (kbd "C-f") (lambda ()
                                (interactive)
                                (let ((inhibit-field-text-motion t))
                                  (goto-char (point-min)))
                                (message "%S"
                                         (read-key
                                          (concat
                                           (make-lines 10)
                                           "\nTest2")))
                                (minibuffer-keyboard-quit)))
  (read-from-minibuffer (concat (make-lines 10) "\nTest1: ") nil map))

The idea here is that the read-key hint will occupy as much space as
the initial read-from-minibuffer.

regards,
Oleh

Message #14 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Oleh Krehel <ohwoeowho <at> gmail.com>
Cc: 39564 <at> debbugs.gnu.org
Subject: Re: bug#39564: 28.0.50;
 read-key function do not display the prompt if called from
 read-from-minibuffer
Date: Tue, 11 Feb 2020 19:36:26 +0200

> From: Oleh Krehel <ohwoeowho <at> gmail.com>
> Date: Tue, 11 Feb 2020 17:17:02 +0100
> 
> Here's an updated code that works as intended on 26.3 and unexpected on 28.
> 
> (defun make-lines (n)
>   (mapconcat #'number-to-string
>              (number-sequence 0 n) "\n"))
> 
> (let ((map (make-sparse-keymap)))
>   (define-key map (kbd "C-f") (lambda ()
>                                 (interactive)
>                                 (let ((inhibit-field-text-motion t))
>                                   (goto-char (point-min)))
>                                 (message "%S"
>                                          (read-key
>                                           (concat
>                                            (make-lines 10)
>                                            "\nTest2")))
>                                 (minibuffer-keyboard-quit)))
>   (read-from-minibuffer (concat (make-lines 10) "\nTest1: ") nil map))
> 
> The idea here is that the read-key hint will occupy as much space as
> the initial read-from-minibuffer.

Thanks, but I still don't understand what should one do with this
snippet (after evaluating it) to see the problem.  Please tell more.

Message #17 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Oleh Krehel <ohwoeowho <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39564 <at> debbugs.gnu.org
Subject: Re: bug#39564: 28.0.50; read-key function do not display the prompt
 if called from read-from-minibuffer
Date: Wed, 12 Feb 2020 14:21:35 +0100

> Thanks, but I still don't understand what should one do with this
> snippet (after evaluating it) to see the problem.  Please tell more.

Here's the behavior in 26.3: the minibuffer is 10 lines tall for
read-from-minibuffer. I'd like read-key to keep the same window height
as not to distract the user, and to have the whole contents of
read-key hint to take over the 10 lines of the minibuffer. Right now,
on 28, the hint is only partially visible. While the behavior on 26.3
and earlier is exactly what I want.

Message #20 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Oleh Krehel <ohwoeowho <at> gmail.com>
Cc: 39564 <at> debbugs.gnu.org
Subject: Re: bug#39564: 28.0.50; read-key function do not display the prompt
 if called from read-from-minibuffer
Date: Wed, 12 Feb 2020 19:22:07 +0200

> From: Oleh Krehel <ohwoeowho <at> gmail.com>
> Date: Wed, 12 Feb 2020 14:21:35 +0100
> Cc: 39564 <at> debbugs.gnu.org
> 
> > Thanks, but I still don't understand what should one do with this
> > snippet (after evaluating it) to see the problem.  Please tell more.
> 
> Here's the behavior in 26.3: the minibuffer is 10 lines tall for
> read-from-minibuffer.

Sorry, I still don't understand: are you saying that you get a 10-line
mini-window after just evaluating the code snippet you posted?  If so,
then I cannot reproduce that: I see a 9-line mini-window, both in
Emacs 26.3 and the current emacs-27 branch (Emacs 27.0.60).

Do I need to do anything after evaluating the code you posted?  (I
think I do, because otherwise I don't understand, for example, why you
bind C-f to some function there.)

Thanks.

Message #23 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Ergus <spacibba <at> aol.com>
To: 39564 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, ohwoeowho <at> gmail.com
Subject: Re: bug#39564: 28.0.50; read-key function do not display the prompt
Date: Wed, 12 Feb 2020 23:37:40 +0100

> Sorry, I still don't understand: are you saying that you get a 10-line
> mini-window after just evaluating the code snippet you posted?  If so,
> then I cannot reproduce that: I see a 9-line mini-window, both in
> Emacs 26.3 and the current emacs-27 branch (Emacs 27.0.60).
> 
> Do I need to do anything after evaluating the code you posted?  (I
> think I do, because otherwise I don't understand, for example, why you
> bind C-f to some function there.)
> 
> Thanks.

I also evaluated the latest code and I get exactly the same behaviour in
emacs 26.3, 27 and 28 (actual master).

Message #26 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Matt Kramer <mccleetus <at> gmail.com>
To: 39564 <at> debbugs.gnu.org
Date: Wed, 26 Feb 2020 12:04:25 -0800

[Message part 1 (text/plain, inline)]

In my case I *do* get different behavior in emacs -Q between 26.3 and
27.0.60 (75a9eee8b). I had to replace minibuffer-keyboard-quit with
abort-recursive-edit, since the former doesn't exist in 26.3. The initial
minibuffer hint looks the same in both cases:

0
1
2
3
4
5
6
7
8
9
10
Test1:
       ^
       |--- cursor

After pressing C-f, 26.3 gives the expected result:

0
1
2
3
4
5
6
7
8
9
10
Test2
     ^
     |--- cursor

However, 27.0.60 gives me the following bizarre content in the minibuffer
(where did that square bracket come from?):

0
1
2
3
4
5
6
7
8
9
10
Test1:  [0
1
2
3
4

in which the cursor is on the 0 at the very top. The read-key function
appears to be identical between the two revisions, aside from a trivial
change to support tab-bar, so I have no idea where the culprit may lie.

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

Message #29 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Matt Kramer <mccleetus <at> gmail.com>
Cc: 39564 <at> debbugs.gnu.org
Subject: Re: bug#39564:
Date: Fri, 28 Feb 2020 09:26:02 +0200

> From: Matt Kramer <mccleetus <at> gmail.com>
> Date: Wed, 26 Feb 2020 12:04:25 -0800
> 
> In my case I *do* get different behavior in emacs -Q between 26.3 and 27.0.60 (75a9eee8b). I had to replace
> minibuffer-keyboard-quit with abort-recursive-edit, since the former doesn't exist in 26.3.

Please show the code you used, and please describe the exact sequence
of keys you type to reproduce the problem in Emacs 27.

Thanks.

Message #32 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Matt Kramer <mccleetus <at> gmail.com>
To: 39564 <at> debbugs.gnu.org
Date: Fri, 28 Feb 2020 09:33:57 -0800

Code I used:

(defun make-lines (n)
  (mapconcat #'number-to-string
             (number-sequence 0 n) "\n"))

(let ((map (make-sparse-keymap)))
  (define-key map (kbd "C-f") (lambda ()
                                (interactive)
                                (let ((inhibit-field-text-motion t))
                                  (goto-char (point-min)))
                                (message "%S"
                                         (read-key
                                          (concat
                                           (make-lines 10)
                                           "\nTest2")))
                                (abort-recursive-edit)))
  (read-from-minibuffer (concat (make-lines 10) "\nTest1: ") nil map))

With this code in the clipboard, I start emacs -Q (again, 27.0.60
commit 75a9eee8b), and immediately hit the following sequence of keys:

C-y
M-x eval-buffer RET
C-f

The eval-buffer results are initially as expected. However, after
hitting C-f, the minibuffer then becomes:

0
1
2
3
4
5
6
7
8
9
10
Test1:  [0
1
2
3
4

with point at the very beginning of the minibuffer (first 0).

Message #35 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Matt Kramer <mccleetus <at> gmail.com>
Cc: 39564 <at> debbugs.gnu.org
Subject: Re: bug#39564:
Date: Sat, 29 Feb 2020 10:16:47 +0200

> From: Matt Kramer <mccleetus <at> gmail.com>
> Date: Fri, 28 Feb 2020 09:33:57 -0800
> 
> Code I used:
> 
> (defun make-lines (n)
>   (mapconcat #'number-to-string
>              (number-sequence 0 n) "\n"))
> 
> (let ((map (make-sparse-keymap)))
>   (define-key map (kbd "C-f") (lambda ()
>                                 (interactive)
>                                 (let ((inhibit-field-text-motion t))
>                                   (goto-char (point-min)))
>                                 (message "%S"
>                                          (read-key
>                                           (concat
>                                            (make-lines 10)
>                                            "\nTest2")))
>                                 (abort-recursive-edit)))
>   (read-from-minibuffer (concat (make-lines 10) "\nTest1: ") nil map))
> 
> With this code in the clipboard, I start emacs -Q (again, 27.0.60
> commit 75a9eee8b), and immediately hit the following sequence of keys:
> 
> C-y
> M-x eval-buffer RET
> C-f
> 
> The eval-buffer results are initially as expected. However, after
> hitting C-f, the minibuffer then becomes:
> 
> 0
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> Test1:  [0
> 1
> 2
> 3
> 4
> 
> with point at the very beginning of the minibuffer (first 0).

Looks like the intended behavior for this code: the "[0 ..." part is
the text of the message displayed by the command bound to C-f; it is
enclosed in brackets to indicate that it is a message text separate
from the rest of the prompt.  This display of echo-area messages that
attempts not to overwrite the minibuffer prompt in an active
minibuffer is a new feature of Emacs 27.  By default, Emacs will not
let the mini-window grow enough to show the entire combined text of
the prompt and the message, but if you set max-mini-window-height to a
value 22 or greater, you will see this:

  0
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  Test1:  [0
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  Test2]

which is what I would expect, given the code you presented.

Going back to the original report, what is the bug here?

Thanks.

Message #38 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Matt Kramer <mccleetus <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39564 <at> debbugs.gnu.org
Subject: Re: bug#39564:
Date: Sun, 1 Mar 2020 14:26:17 -0800

Thanks Eli for the explanation. Sorry for the trouble. It looks like
Ivy (at least, in ivy-dispatching-done) assumes the old behavior, to
wit, that echo-area messages will overwrite the minibuffer prompt,
leading to the regression discussed in
https://github.com/abo-abo/swiper/issues/2444. The conversation will
continue over there, I guess.

On Sat, Feb 29, 2020 at 12:17 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Matt Kramer <mccleetus <at> gmail.com>
> > Date: Fri, 28 Feb 2020 09:33:57 -0800
> >
> > Code I used:
> >
> > (defun make-lines (n)
> >   (mapconcat #'number-to-string
> >              (number-sequence 0 n) "\n"))
> >
> > (let ((map (make-sparse-keymap)))
> >   (define-key map (kbd "C-f") (lambda ()
> >                                 (interactive)
> >                                 (let ((inhibit-field-text-motion t))
> >                                   (goto-char (point-min)))
> >                                 (message "%S"
> >                                          (read-key
> >                                           (concat
> >                                            (make-lines 10)
> >                                            "\nTest2")))
> >                                 (abort-recursive-edit)))
> >   (read-from-minibuffer (concat (make-lines 10) "\nTest1: ") nil map))
> >
> > With this code in the clipboard, I start emacs -Q (again, 27.0.60
> > commit 75a9eee8b), and immediately hit the following sequence of keys:
> >
> > C-y
> > M-x eval-buffer RET
> > C-f
> >
> > The eval-buffer results are initially as expected. However, after
> > hitting C-f, the minibuffer then becomes:
> >
> > 0
> > 1
> > 2
> > 3
> > 4
> > 5
> > 6
> > 7
> > 8
> > 9
> > 10
> > Test1:  [0
> > 1
> > 2
> > 3
> > 4
> >
> > with point at the very beginning of the minibuffer (first 0).
>
> Looks like the intended behavior for this code: the "[0 ..." part is
> the text of the message displayed by the command bound to C-f; it is
> enclosed in brackets to indicate that it is a message text separate
> from the rest of the prompt.  This display of echo-area messages that
> attempts not to overwrite the minibuffer prompt in an active
> minibuffer is a new feature of Emacs 27.  By default, Emacs will not
> let the mini-window grow enough to show the entire combined text of
> the prompt and the message, but if you set max-mini-window-height to a
> value 22 or greater, you will see this:
>
>   0
>   1
>   2
>   3
>   4
>   5
>   6
>   7
>   8
>   9
>   10
>   Test1:  [0
>   1
>   2
>   3
>   4
>   5
>   6
>   7
>   8
>   9
>   10
>   Test2]
>
> which is what I would expect, given the code you presented.
>
> Going back to the original report, what is the bug here?
>
> Thanks.

Message #41 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Matt Kramer <mccleetus <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39564 <at> debbugs.gnu.org
Subject: Re: bug#39564:
Date: Sun, 1 Mar 2020 23:20:23 -0800

Followup: The regression in Ivy appears to be fixed when
set-message-function is bound to nil at the top of the misbehaving
function. In general, it seems like, given the new defaults defined in
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=485b423e8f0df2711a850be7f254665f64ab0bdb,
it will be necessary to make a similar change to any existing function
that, say, calls read-key under the assumption that the prompt will
take over the mini-window. (At least when the prompt contains multiple
lines). I guess that's the fundamental issue here. The new behavior
may be a nice improvement, but it's unclear how much code there is out
there that relies on the old behavior.

(For the record, it looks like the Ivy discussion has moved to
https://github.com/abo-abo/swiper/issues/2397)

On Sun, Mar 1, 2020 at 2:26 PM Matt Kramer <mccleetus <at> gmail.com> wrote:
>
> Thanks Eli for the explanation. Sorry for the trouble. It looks like
> Ivy (at least, in ivy-dispatching-done) assumes the old behavior, to
> wit, that echo-area messages will overwrite the minibuffer prompt,
> leading to the regression discussed in
> https://github.com/abo-abo/swiper/issues/2444. The conversation will
> continue over there, I guess.
>
> On Sat, Feb 29, 2020 at 12:17 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Matt Kramer <mccleetus <at> gmail.com>
> > > Date: Fri, 28 Feb 2020 09:33:57 -0800
> > >
> > > Code I used:
> > >
> > > (defun make-lines (n)
> > >   (mapconcat #'number-to-string
> > >              (number-sequence 0 n) "\n"))
> > >
> > > (let ((map (make-sparse-keymap)))
> > >   (define-key map (kbd "C-f") (lambda ()
> > >                                 (interactive)
> > >                                 (let ((inhibit-field-text-motion t))
> > >                                   (goto-char (point-min)))
> > >                                 (message "%S"
> > >                                          (read-key
> > >                                           (concat
> > >                                            (make-lines 10)
> > >                                            "\nTest2")))
> > >                                 (abort-recursive-edit)))
> > >   (read-from-minibuffer (concat (make-lines 10) "\nTest1: ") nil map))
> > >
> > > With this code in the clipboard, I start emacs -Q (again, 27.0.60
> > > commit 75a9eee8b), and immediately hit the following sequence of keys:
> > >
> > > C-y
> > > M-x eval-buffer RET
> > > C-f
> > >
> > > The eval-buffer results are initially as expected. However, after
> > > hitting C-f, the minibuffer then becomes:
> > >
> > > 0
> > > 1
> > > 2
> > > 3
> > > 4
> > > 5
> > > 6
> > > 7
> > > 8
> > > 9
> > > 10
> > > Test1:  [0
> > > 1
> > > 2
> > > 3
> > > 4
> > >
> > > with point at the very beginning of the minibuffer (first 0).
> >
> > Looks like the intended behavior for this code: the "[0 ..." part is
> > the text of the message displayed by the command bound to C-f; it is
> > enclosed in brackets to indicate that it is a message text separate
> > from the rest of the prompt.  This display of echo-area messages that
> > attempts not to overwrite the minibuffer prompt in an active
> > minibuffer is a new feature of Emacs 27.  By default, Emacs will not
> > let the mini-window grow enough to show the entire combined text of
> > the prompt and the message, but if you set max-mini-window-height to a
> > value 22 or greater, you will see this:
> >
> >   0
> >   1
> >   2
> >   3
> >   4
> >   5
> >   6
> >   7
> >   8
> >   9
> >   10
> >   Test1:  [0
> >   1
> >   2
> >   3
> >   4
> >   5
> >   6
> >   7
> >   8
> >   9
> >   10
> >   Test2]
> >
> > which is what I would expect, given the code you presented.
> >
> > Going back to the original report, what is the bug here?
> >
> > Thanks.

Message #44 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Matt Kramer <mccleetus <at> gmail.com>
Cc: 39564 <at> debbugs.gnu.org
Subject: Re: bug#39564:
Date: Mon, 02 Mar 2020 10:46:50 +0200

> From: Matt Kramer <mccleetus <at> gmail.com>
> Date: Sun, 1 Mar 2020 23:20:23 -0800
> Cc: 39564 <at> debbugs.gnu.org
> 
> Followup: The regression in Ivy appears to be fixed when
> set-message-function is bound to nil at the top of the misbehaving
> function.

That is indeed the simplest solution, but it is not the best one.  It
would be better for Ivy to provide its own set-message-function which
plays by the new Emacs 27 rules, i.e. presents the message text in a
way that doesn't completely obscure the original prompt.

> In general, it seems like, given the new defaults defined in
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=485b423e8f0df2711a850be7f254665f64ab0bdb,
> it will be necessary to make a similar change to any existing function
> that, say, calls read-key under the assumption that the prompt will
> take over the mini-window. (At least when the prompt contains multiple
> lines). I guess that's the fundamental issue here. The new behavior
> may be a nice improvement, but it's unclear how much code there is out
> there that relies on the old behavior.

Relying on the old behavior was always not a future-proof assumption,
so I see no way around the problem except fixing the code which makes
such assumptions, sorry.

Message #47 received at 39564 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39564 <at> debbugs.gnu.org, Matt Kramer <mccleetus <at> gmail.com>
Subject: Re: bug#39564: 28.0.50; read-key function do not display the prompt
 if called from read-from-minibuffer
Date: Sun, 20 Feb 2022 16:13:43 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Relying on the old behavior was always not a future-proof assumption,
> so I see no way around the problem except fixing the code which makes
> such assumptions, sorry.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Reading this bug report, it seems the conclusion was that this was a
problem in Ivy, and not in Emacs?  So I'm therefore closing this bug
report.  If something should be done on the Emacs side, please respond
to the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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