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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66773 in the body.
You can then email your comments to 66773 AT debbugs.gnu.org in the normal way.

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

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

From: Spencer Williams <spnw <at> plexwave.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1; Ido displays incorrectly with multiple frames when
 ido-max-window-height=1
Date: Thu, 26 Oct 2023 16:15:07 -0400

When using multiple graphical frames, setting ido-max-window-height to 1
only works as expected on the initial frame. On all other frames,
supposing the minibuffer length is great enough, the beginning will be
occluded until user input is received.

This can be easily demonstrated by running the following code on a fresh
graphical Emacs, and then pressing C-x b to switch buffers:

(progn
  (ido-mode 1)
  (setq ido-max-window-height 1)
  (dotimes (i 100)
    (generate-new-buffer "foobar"))
  (make-frame))

The bug manifests on both Linux and macOS (vanilla builds). It was not
present on Emacs 28. I ran a git-bisect and the "first bad commit"
appears to be c0b9041ebde82907711cc00a7c307fe622fb541c.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Williams <spnw <at> plexwave.org>
Cc: 66773 <at> debbugs.gnu.org
Subject: Re: bug#66773: 29.1;
 Ido displays incorrectly with multiple frames when
 ido-max-window-height=1
Date: Fri, 27 Oct 2023 13:49:56 +0300

> Date: Thu, 26 Oct 2023 16:15:07 -0400
> From:  Spencer Williams via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> When using multiple graphical frames, setting ido-max-window-height to 1
> only works as expected on the initial frame. On all other frames,
> supposing the minibuffer length is great enough, the beginning will be
> occluded until user input is received.
> 
> This can be easily demonstrated by running the following code on a fresh
> graphical Emacs, and then pressing C-x b to switch buffers:
> 
> (progn
>   (ido-mode 1)
>   (setq ido-max-window-height 1)
>   (dotimes (i 100)
>     (generate-new-buffer "foobar"))
>   (make-frame))
> 
> The bug manifests on both Linux and macOS (vanilla builds). It was not
> present on Emacs 28. I ran a git-bisect and the "first bad commit"
> appears to be c0b9041ebde82907711cc00a7c307fe622fb541c.

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.

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.  The change to which you point affect general Emacs
behavior, it isn't specific to ido-mode.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Williams <spnw <at> plexwave.org>
Cc: 66773 <at> debbugs.gnu.org
Subject: Re: bug#66773: 29.1; Ido displays incorrectly with multiple frames
 when ido-max-window-height=1
Date: Sat, 28 Oct 2023 11:22:59 +0300

> From: Spencer Williams <spnw <at> plexwave.org>
> Cc: 66773 <at> debbugs.gnu.org
> Date: Fri, 27 Oct 2023 18:47:40 -0400
> 
> 
> Eli Zaretskii <eliz <at> 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.

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

From: Spencer Williams <spnw <at> plexwave.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66773 <at> debbugs.gnu.org
Subject: Re: bug#66773: 29.1; Ido displays incorrectly with multiple frames
 when ido-max-window-height=1
Date: Fri, 27 Oct 2023 18:47:40 -0400

Eli Zaretskii <eliz <at> 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.

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

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

From: Spencer Williams <spnw <at> plexwave.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 66773 <at> debbugs.gnu.org
Subject: Re: bug#66773: 29.1; Ido displays incorrectly with multiple frames
 when ido-max-window-height=1
Date: Sat, 28 Oct 2023 19:41:45 -0400

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

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

There is no change when reverting it against Emacs 29 or master. I
apologize for not mentioning this before. There is a change, however,
when reverting against the commit's immediate parent; so, coincidentally
or otherwise, the commit does manifest the behavior I've demonstrated. I
cannot speak to the ramifications for the rest of the codebase (I
understand much has likely changed in the two years since that commit
was made).

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

That is certainly interesting, as I can affirm this behavior was not
present in any version of Emacs 28 I've tested (up to emacs-28.3-rc1).

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

It does, and I thank you much for turning me onto that, as it at least
provides a usable fix for now.

Message #22 received at 66773-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Williams <spnw <at> plexwave.org>
Cc: 66773-done <at> debbugs.gnu.org
Subject: Re: bug#66773: 29.1; Ido displays incorrectly with multiple frames
 when ido-max-window-height=1
Date: Sat, 18 Nov 2023 10:34:50 +0200

> From: Spencer Williams <spnw <at> plexwave.org>
> Cc: 66773 <at> debbugs.gnu.org
> Date: Sat, 28 Oct 2023 19:41:45 -0400
> 
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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.
> 
> It does, and I thank you much for turning me onto that, as it at least
> provides a usable fix for now.

No more comments, so I'm now closing the bug as done.

Previous Next

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