bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#66773: 29.1; Ido displays incorrectly with multiple frames when ido-


From: Eli Zaretskii
Subject: 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@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]