bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Sat, 19 Sep 2020 13:54:13 -0400
>> 
>>     % src/emacs -Q --eval '(setq max-mini-window-height 1)' -f icomplete-mode
>>     M-x a
>> 
>> at this point, you should presumably not see the "M-x a" in your
>> minibuffer window but only something of the form "{rp | lign | ..."
>
> Seems like a bug in icomplete: it attempts to compute the maximum
> length of candidates to be displayed, but seems like it fails, because
> the single mini-window line is continued, with no ellipsis at the end
> of the visible line?

I disagree: icomplete merely added text after point via an overlay and
didn't do anything which explicitly justifies horizontal scrolling.

I suspect the problem is that point is right on the overlay, so in
a sense it's both before *and* after the "{...}" text.  Conceptually it
should be considered as being before (which is why the cursor is placed
on the `{`), and the redisplay somewhat agrees with it (because it
hides the end of "{...}" rather than its beginning) but not completely
since it scrolled the display even though the `{` was already visible
without it.

> The fact that it calls window-width with no arguments is one possible
> problem -- it assumes the default face's font.  But I think the
> problem is more prominent than just that.
>
> It should produce an overlay string that fits in the window, then the
> prompt will be visible.

That would merely work around the underlying problem (and as you know
it's wickedly difficult to construct a string which will have "just the
right size" to fit into the minibuffer window).

Maybe there's a good reason for the redisplay to behave this way, but if
that's the case we need some way for icomplete (and other similar cases)
to make it behave differently.


        Stefan