GNU bug report logs - #35006
27.0.50; Minibuffer sometimes unexpectedly does not grow

Previous Next

To reply to this bug, email your comments to 35006 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Minibuffer sometimes unexpectedly does not grow
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.


In GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin18.0.0, X toolkit, Xaw scroll bars)
 of 2018-11-15 built on mt-computer
Repository revision: b4eb908f858284a7962851fd99c94598f76afa6f
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000

Message #8 received at 35006 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 35006 <at> debbugs.gnu.org
Subject: Re: bug#35006: 27.0.50;
 Minibuffer sometimes unexpectedly does not grow
Date: Tue, 26 Mar 2019 20:41:04 +0200

> From: Markus Triska <triska <at> 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.

You didn't say how to evaluate that; there's more than one way.  If I
evaluate with "M-x eval-region RET", the mini-window doesn't grow; if
I evaluate with "C-x C-e" or C-j after the closing parenthesis, it
does grow.

So it sounds like one doesn't need such a complex recipe, the
different behavior is visible already on the first evaluation.

Message #11 received at 35006 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 35006 <at> debbugs.gnu.org
Subject: Re: bug#35006: 27.0.50;
 Minibuffer sometimes unexpectedly does not grow
Date: Wed, 27 Mar 2019 19:55:32 +0200

> From: Markus Triska <triska <at> 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.

Message #14 received at 35006 <at> debbugs.gnu.org (full text, mbox):

From: Markus Triska <triska <at> metalevel.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35006 <at> debbugs.gnu.org
Subject: Re: bug#35006: 27.0.50;
 Minibuffer sometimes unexpectedly does not grow
Date: Wed, 27 Mar 2019 22:00:07 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> I think you expect resize-mini-windows to do what it was never
> designed to do.

I was relying on the guarantee outlined in the info material:

   The minibuffer’s window is normally a single line; it grows
   automatically if the contents require more space.

In the case I posted, the contents indeed require more space, but
unfortunately the minibuffer does not grow automatically.

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

Could you please consider supporting this feature? It would be very
useful for an application I am currently working on.

Message #17 received at 35006 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 35006 <at> debbugs.gnu.org
Subject: Re: bug#35006: 27.0.50;
 Minibuffer sometimes unexpectedly does not grow
Date: Thu, 28 Mar 2019 05:33:27 +0200

> From: Markus Triska <triska <at> metalevel.at>
> Cc: 35006 <at> debbugs.gnu.org
> Date: Wed, 27 Mar 2019 22:00:07 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I think you expect resize-mini-windows to do what it was never
> > designed to do.
> 
> I was relying on the guarantee outlined in the info material:
> 
>    The minibuffer’s window is normally a single line; it grows
>    automatically if the contents require more space.

The documentation doesn't consider the case of inserting arbitrary
content in the minibuffer.

> > 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.
> 
> Could you please consider supporting this feature?

I will take a look, but no promises.  This is something redisplay
never does, for any window.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.