From: Matt Kramer <mccleetus@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 39564@debbugs.gnu.org
Subject: bug#39564:
Date: Sun, 1 Mar 2020 14:26:17 -0800 [thread overview]
Message-ID: <CANGn5a73cF9sGWDpk0xNzebw+G0LKSrNz0rs_SuD==-cqf4Cdg@mail.gmail.com> (raw)
In-Reply-To: <83pndxerkg.fsf@gnu.org>
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.
next prev parent reply other threads:[~2020-03-01 22:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200211144941.godmcifegapmqg6i.ref@Ergus>
2020-02-11 14:49 ` bug#39564: 28.0.50; read-key function do not display the prompt if called from read-from-minibuffer Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-02-11 15:50 ` Eli Zaretskii
2020-02-11 16:17 ` Oleh Krehel
2020-02-11 17:36 ` Eli Zaretskii
2020-02-12 13:21 ` Oleh Krehel
2020-02-12 17:22 ` Eli Zaretskii
2020-02-12 22:37 ` bug#39564: 28.0.50; read-key function do not display the prompt Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-02-26 20:04 ` bug#39564: Matt Kramer
2020-02-28 7:26 ` bug#39564: Eli Zaretskii
2020-02-28 17:33 ` bug#39564: Matt Kramer
2020-02-29 8:16 ` bug#39564: Eli Zaretskii
2020-03-01 22:26 ` Matt Kramer [this message]
2020-03-02 7:20 ` bug#39564: Matt Kramer
2020-03-02 8:46 ` bug#39564: Eli Zaretskii
2022-02-20 15:13 ` bug#39564: 28.0.50; read-key function do not display the prompt if called from read-from-minibuffer Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANGn5a73cF9sGWDpk0xNzebw+G0LKSrNz0rs_SuD==-cqf4Cdg@mail.gmail.com' \
--to=mccleetus@gmail.com \
--cc=39564@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).