bug#44933: 27.1; Ephemeral frame selection shrinks minibuffer

[Sean Devlin <spd@toadstyle.org>]

Hi Martin,

> On Nov 29, 2020, at 3:22 AM, martin rudalics <rudalics@gmx.at> wrote:
> 
> > Selecting a different frame ephmerally (e.g. via `with-selected-frame`
> > in a timer callback) shrinks the minibuffer. This is true whether or not
> > the minibuffer is active.
> >
> > Reproduction steps:
> >
> > 1. Evaluate this form in the scratch buffer:
> >
> >     (run-with-timer nil 13 (lambda () (with-selected-frame
> >     (next-frame))))
> >
> > 2. Evaluate this form in the scratch buffer:
> >
> >     (run-with-timer nil 11 (lambda () (window-resize (minibuffer-window)
> >     10)))
> >
> > 3. Observe that the minibuffer grows and shrinks as the timers fire.
> 
> Here I need two frames to observe 3.  With one frame the minibuffer
> window grows continuously.

Ah, you’re right. I had left this out of my reproduction steps. Sorry!

> 
> > You can run some completing read command (e.g. `M-x`) to see that the
> > resizing happens whether or not the minibuffer is active.
> >
> > This is relevant for completing read implementations that resize the
> > minibuffer to display a vertical list of candidates. I noticed the
> > behavior while using selectrum (https://github.com/raxod502/selectrum)
> > while I had a subprocess running under term in another frame. Since the
> > `term-emulate-terminal` function selects windows in the background
> > whenever the subprocess sends output, it was causing the selectrum
> > minibuffer to shrink.
> >
> > I'm not sure what the correct behavior is here, but this was unexpected
> > to me. I think that if the minibuffer is active, ephemeral frame or
> > window selections should not affect its size. (I'm less certain about
> > the inactive minibuffer case, but I think the size should stay the same
> > there as well.)
> 
> To my knowledge we have no means to select a frame "ephemerally".
> 'with-selected-frame', 'with-selected-window' are just as "hard" as
> 'select-frame' and 'select-window'.  And so the only way to prevent
> switching frames from shrinking the previously selected frame's
> minibuffer window is to set 'resize-mini-windows' to nil.  OTOH with
> 'resize-mini-windows' non-nil, re-selecting the previously selected frame
> when returning from a 'with-selected-frame' should size its minibuffer
> window back to its contents provided it is still active.  But I'm never
> sure whether all these work as advertised.

I see, thank you.

It looks like the default value for `resize-mini-windows` is
`grow-only`. The docs for `resize-mini-windows` suggest it is used
along with the text in the minibuffer to decide how to resize the
window. I think this may be the issue, since my minibuffer has no text
spanning multiple lines.

In my reproduction, the minibuffer window is grown manually via
`window-resize`. In the case of selectrum, the completing read
candidates are displayed via overlay. I think this means that a
resizing function that considers the buffer text only will resize
these back down to a single line.

I just tested, and binding `resize-mini-windows` to nil around the
window selection in `term-emulate-terminal` does solve my
problem. Does this seem like the right fix? I think it is surprising
that output from a term process coming in the background should resize
a minibuffer window (and especially an active one).

Also, I see that `term-emulate-terminal` is calling `select-window` to
perform its window selections. From my reading of the docs, I think it
might make sense for it to pass `mark-for-redisplay` as the `norecord`
argument. It doesn't seem like we should be modifying the buffer list
or most recently selected window in this case, but we do want to
redisplay the new output.

I think the documentation should clarify that window selection can
change window sizes as a side effect. The docs for selecting windows
(https://www.gnu.org/software/emacs/manual/html_node/elisp/Selecting-Windows.html)
do not mention that `select-window` can change minibuffer sizes. The
docs for minibuffer windows
(https://www.gnu.org/software/emacs/manual/html_node/elisp/Minibuffer-Windows.html)
do mention these variables to control how minibuffer windows can be
resized automatically, but they do not say what functions might try to
do this automatic resizing.

Finally, I wonder if `with-selected-window` (which
`term-emulate-terminal` does not currently use) should bind
`resize-mini-windows`. The docs say it is "the preferred way to
temporarily work with" a selected window, so it does seem like
automatic resizing is not in the spirit of the function. On the other
hand, I don't know all the existing use cases; maybe this would break
things.

Thanks!

> 
> martin