bug#60015: 29.0.60; multi-line messages truncated in non-selected minibuffer

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 60015@debbugs.gnu.org
> Date: Tue, 13 Dec 2022 19:20:06 +0200
> 
> >> > Doesn't happen here (I waited for 2.5 minutes).  Is the recipe
> >> > complete and exact?  Does it perhaps matter how do you "switch back to
> >> > the original buffer"?  (I used a mouse click.)
> >>
> >> It's essential to ensure that the height of the minibuffer/echo area
> >> initially is not more than 1 line.
> >
> > That's so by default, so "emacs -Q" should ensure that.  Right?
> 
> Evaluating the first line above resizes the minibuffer,
> and the timer resizes the minibuffer, so it's difficult
> to find a moment when it's exactly 1 line high.

You said "initially", so I thought you were talking about what
happens before the recipe is started.

Are you saying that you see the echo-area go down to 1 line _after_
the timer is started?  If so, to unlock this puzzle we need to
understand what causes the mini-window to resize back to 1 line.  The
default value of resize-mini-windows is 'grow-only', so it isn't
supposed to shrink back to 1 line.

> >> > When the problem happens, what do you see in *Messages*?  Anything
> >> > other that "abc\ndef"?
> >>
> >> Only the first line "abc" is displayed in the minibuffer
> >> as the minibuffer message.
> >
> > I asked about the *Messages* buffer, not about the minibuffer.
> 
> Sorry.  The *Messages* buffer shows all lines of the multi-line string.

And nothing else?  I hoped you will see there something that would
explain why the mini-window resized back to 1 line.