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

[Dmitry Gutov]

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.