bug#39564:

[Matt Kramer]

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@gnu.org> wrote:
>
> > From: Matt Kramer <mccleetus@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.