bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Williams <spnw@plexwave.org>
> Cc: 66773@debbugs.gnu.org
> Date: Fri, 27 Oct 2023 18:47:40 -0400
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If the minibuffer text is longer than what the mini-window can show,
> > then it is not clear whether Emacs should show the beginning or the
> > end of the minibuffer text.  So I don't see how this is a bug and why
> > would the alternative behavior be better.  Also, if you just type C-b,
> > you will see the rest of the buffer text.
> 
> I consider it a bug due to inconsistent behavior. With multiple
> frames, the behavior is different than it is with only one frame.

OK, I didn't understand this from your original report, sorry.

But in that case, the result of Git bisection is incorrect, since
reverting that commit doesn't change the behavior in this recipe, at
least on my system.  Did you see any change in behavior when you
reverted the commit to which "git bisect" pointed?

> > If, for some reason, ido-mode wants to always display the beginning of
> > the minibuffer text, it can do that with a change specific to
> > ido-mode.
> 
> In Ido's case it is certainly incorrect to show the end first, due to
> the prompt and selection being at the beginning. My concern is that in
> Emacs 28 it had no trouble, and in Emacs 29 it acts erratically.
> 
> > The change to which you point affect general Emacs behavior, it
> > isn't specific to ido-mode.
> 
> I understand that. I originally meant for this report to be more
> general, as I did believe Emacs's drawing code to be at fault, but in
> the end Ido was the only definitive example of wrong behavior I could
> reproduce. I included the commit reference on the outside chance it
> might save someone some digging (as I'd already put a little work into
> finding a solution myself).
> 
> I hope that if it is indeed an Ido-specific bug, this report will still
> be of some use. Thanks for your time.

The reason for what you see is the new handling of mini-windows
introduced in Emacs 28 (not in 29), whereby by default we show the end
of the mini-buffer text, not its beginning.  It looks to me that when
ido-max-window-height is set to 1, the variable
redisplay-adhoc-scroll-in-resize-mini-windows should be set to the nil
value, which will make the behavior in your recipe consistent, at
least in my testing.