bug#67715: 28.2; Minibuffer content is sometimes unexpectedly partially hidden

[Eli Zaretskii]

tags 67715 wontfix
thanks

> From: Markus Triska <triska@metalevel.at>
> Date: Fri, 08 Dec 2023 20:03:32 +0100
> 
> To reproduce the issue, please start Emacs with:
> 
>     $ emacs -Q
> 
> Then put the following form in the *scratch* buffer and evaluate it with
> C-x e:
> 
>     (let ((f (selected-frame)))
>       (with-selected-frame (make-frame)
>         (switch-to-buffer (get-buffer-create "other")))
>       (select-frame-set-input-focus f)
>       (let ((win (get-buffer-window "other" t)))
>         (when win
>           (with-selected-window win
>             (recenter 0)))
>         (with-selected-window (minibuffer-window)
>           (unwind-protect
>               (progn
>                 (setq-local face-remapping-alist `((default :height 2.0)))
>                 (insert "hello")
>                 (read-key))
>             (erase-buffer)))))
> 
> "hello" is shown in the minibuffer, but it is partially hidden.
> 
> For comparison, in Emacs 28.1, "hello" is fully visible.
> 
> Can you reproduce this issue, and if possible, could you please restore
> the behaviour of Emacs 28.1 and earlier versions for this example?

The change which caused this cannot be reverted, since it will
reintroduce a worse bug (bug#24285).

Why did you expect the mini-window to resize in this case?  Emacs
doesn't resize a window just because you enlarge a font shown in that
window, which makes some of the text invisible because it not longer
fits into the window's dimensions.  The automatic resizing of the
mini-window is reserved for its uses to prompt the user and to show
echo-area messages, whereas your snippet just uses it as a normal
window showing some buffer.

So I don't think we will change this behavior, and you will need to
find another way of ensuring the enlarged text is visible, in your
real-life use case.

Sorry.