bug#24293: 25.1; Display bug: icomplete prompt not visible with icomplete-separator "\n"

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Date: Tue, 23 Aug 2016 17:44:12 +0200
> 
> In emacs -Q, eval
> 
>   (setq icomplete-separator "\n")
> 
> and do
> 
>   M-x icomplete-mode <return>
> 
> Then, e.g.
> 
>   M-x m
> 
> The icomplete minibuffer prompt is invisible (bug).
> 
> But you see that it's "there" when you hit <left>.  And changing the
> value of `resize-mini-windows' to nil makes the issue disappear - so I
> think this is caused by a problem in the display code.

Surprisingly, stepping through the code with a debugger reveals that
this is not a bug, but (almost) deliberate behavior.  Set
max-mini-window-height to 0.9, and you will see the entire prompt.

The default value of that variable is 0.25, so Emacs doesn't resize
mini-windows to more than 1/4th of the height of the frame's root
window.  And the height required to show the prompt is much larger in
this case.  So the mini-window is only resized to 9 lines, and Emacs
then attempts to show the last part of the minibuffer text that fits
in the mini-window.  You can see this in action if you evaluate this:

  (message "1\n2\n3\n4\n5\n6\n7\n8\n9\n0\n1\n")

What happens next is that the after-string causes the display to start
at the beginning of the string, because Emacs cannot start the
window's display in the middle of an overlay string.  So what is
actually shown is not the end, but the middle of the overlay string.

Not sure what, if anything, to do with this.  IMO, in this situation
showing anything at all will not serve the user well enough, so I tend
to do nothing and argue that displaying minibuffer text that requires
so many lines cannot possibly work well anyway, and when the text ends
with a multi-line overlay string, we hit a limitation of the display
engine.

Thanks.