From: Eli Zaretskii <eliz@gnu.org>
To: Markus Triska <triska@metalevel.at>
Cc: 35006@debbugs.gnu.org
Subject: bug#35006: 27.0.50; Minibuffer sometimes unexpectedly does not grow
Date: Wed, 27 Mar 2019 19:55:32 +0200 [thread overview]
Message-ID: <837eckkxrf.fsf@gnu.org> (raw)
In-Reply-To: <m236n94k6g.fsf@metalevel.at> (message from Markus Triska on Tue, 26 Mar 2019 18:31:03 +0100)
> From: Markus Triska <triska@metalevel.at>
> Date: Tue, 26 Mar 2019 18:31:03 +0100
>
> Please start Emacs with "emacs -Q", and then evaluate in the
> *scratch* buffer the following form:
>
> (with-selected-window (minibuffer-window)
> (erase-buffer)
> (insert (propertize "hello" 'face '(:height 2.0)))
> (read-key)
> (erase-buffer))
>
> This shows "hello" in the minibuffer, and the minibuffer grows as
> expected. Please press a key (or C-g) to continue.
>
> Next, please make a frame, say "F", with the form:
>
> (make-frame '((name . "F")))
>
> In F, please press:
>
> M-x C-g
>
> This simply enters and exits the minibuffer.
>
> Then, in the original frame, evaluate again the form above, i.e.:
>
> (with-selected-window (minibuffer-window)
> (erase-buffer)
> (insert (propertize "hello" 'face '(:height 2.0)))
> (read-key)
> (erase-buffer))
>
> Unexpectedly, the minibuffer is now no longer grown in the (selected)
> frame where this form is evaluated (again), and therefore the inserted
> text is now not fully visible, in contrast to the first time.
I think you expect resize-mini-windows to do what it was never
designed to do.
This feature is supposed to resize mini-windows for the purposes of
interacting with the user, i.e. for displaying messages in the
echo-area, and for prompting the user for input and receiving input in
response. You are doing something different: you insert arbitrary
text into a mini-window's buffer, which is a normal buffer operation
not specific to mini-windows. The text you insert is displayed as
part of normal redisplay of all the windows, not as user interaction
via the mini-window. So in that case, the mini-window is just like
any other window, and those don't resize automatically to accommodate
the text you inserted when they are redisplayed.
Maybe it's a flaw that should be fixed by enhancing the design and
making the implementation follow suit, but currently the code works as
designed, AFAICT.
next prev parent reply other threads:[~2019-03-27 17:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-26 17:31 bug#35006: 27.0.50; Minibuffer sometimes unexpectedly does not grow Markus Triska
2019-03-26 18:41 ` Eli Zaretskii
2019-03-27 17:55 ` Eli Zaretskii [this message]
2019-03-27 21:00 ` Markus Triska
2019-03-28 3:33 ` Eli Zaretskii
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=837eckkxrf.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=35006@debbugs.gnu.org \
--cc=triska@metalevel.at \
/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).