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