bug#39564:

[Eli Zaretskii <eliz@gnu.org>]

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