GNU bug report logs -
#39379
27.0.60; Fix for #38457 broke ido-vertical-mode
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 5 years and 105 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.