* bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 @ 2023-10-26 20:15 Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-10-27 10:49 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-26 20:15 UTC (permalink / raw) To: 66773 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 2023-10-26 20:15 bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-27 10:49 ` Eli Zaretskii 2023-10-27 22:47 ` Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 6+ messages in thread From: Eli Zaretskii @ 2023-10-27 10:49 UTC (permalink / raw) To: Spencer Williams; +Cc: 66773 > 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@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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 2023-10-27 10:49 ` Eli Zaretskii @ 2023-10-27 22:47 ` Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-10-28 8:22 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-27 22:47 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 66773 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. > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 2023-10-27 22:47 ` Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-28 8:22 ` Eli Zaretskii 2023-10-28 23:41 ` Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 6+ messages in thread From: Eli Zaretskii @ 2023-10-28 8:22 UTC (permalink / raw) To: Spencer Williams; +Cc: 66773 > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 2023-10-28 8:22 ` Eli Zaretskii @ 2023-10-28 23:41 ` Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-11-18 8:34 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-28 23:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 66773 Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 2023-10-28 23:41 ` Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-18 8:34 ` Eli Zaretskii 0 siblings, 0 replies; 6+ messages in thread From: Eli Zaretskii @ 2023-11-18 8:34 UTC (permalink / raw) To: Spencer Williams; +Cc: 66773-done > From: Spencer Williams <spnw@plexwave.org> > Cc: 66773@debbugs.gnu.org > Date: Sat, 28 Oct 2023 19:41:45 -0400 > > > Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-11-18 8:34 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-10-26 20:15 bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-max-window-height=1 Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-10-27 10:49 ` Eli Zaretskii 2023-10-27 22:47 ` Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-10-28 8:22 ` Eli Zaretskii 2023-10-28 23:41 ` Spencer Williams via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-11-18 8:34 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.