[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39564:
From: |
Eli Zaretskii |
Subject: |
bug#39564: |
Date: |
Sat, 29 Feb 2020 10:16:47 +0200 |
> 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.