[Top][All Lists]

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

bug#39379: 27.0.60; Fix for #38457 broke ido-vertical-mode

From: Dmitry Gutov
Subject: bug#39379: 27.0.60; Fix for #38457 broke ido-vertical-mode
Date: Wed, 12 Feb 2020 01:42:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 10.02.2020 17:44, Eli Zaretskii wrote:
So now, after thinking about this for some time, I think I want to
change my mind and ask why do we need to use an overlay with
after-string in ido.el?  Re-reading related discussions, it seems the
answer is "so that the temporary display of messages is not at the end
of the minibuffer, where it could be invisible due to
resize-mini-windows being nil or restrictions imposed by ido.el via
ido-max-window-height".  Is that the correct conclusion?  If so, then
I think we can solve that problem without overlays.  See the proposed
patch below, which basically reverts ido.el to its previous shape, and
uses a special text property to instruct set-minibuffer-message where
to put the overlay (defaulting to EOB).

The patch more or less works, with the exception of the case where POS is EOB (e.g. when the sole completion is fully typed out). But that should be fixable as well.

The reason I used after-string, though, is that icomplete-mode does that. And either it should have the same problems, or ido creates some circumstances where the problems show up.

The former seems to be the case, though. Like, if I set max-mini-window-height to 1, then icomplete-mode also exhibits bug#39433.

And while there is no xxx-vertical-mode for icomplete-mode, we would probably want one to be written someday. Sounds like when that happens, icomplete-vertical-mode would trigger this same bug as well unless we fix it in the display engine or find some other general way to avoid it.

reply via email to

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