[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39564:
From: |
Matt Kramer |
Subject: |
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@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.
- bug#39564:,
Matt Kramer <=