bug#39564:

[Matt Kramer <mccleetus@gmail.com>]

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