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

[Gregory Heytings]

> > Perhaps I misunderstood something, but for me "start the display at the 
> > beginning of the screen line where we end up after 
> > move_it_vertically_backward" would mean that if the prompt and the user 
> > input so far needs more than one line, only the last line would be 
> > displayed.  So instead of having, say,
> >
> > Find file: <user input>
> > <user input>|
> > <completion candidates>
> >
> > (where | represents the cursor) we would only have:
> >
> > <user input>|
> > <completion candidates>
>
> Yes.
>
> This bug was filed to request that Emacs behaves with overlay-string in 
> the minibuffer prompt the same as with regular buffer text.

Hmmm...  no, this bug was filed after a discussion on emacs-devel (about 
implementing vertical icomplete), and the problem is clearly stated by 
Stefan: the prompt and user input so far disappear.

> What I propose will do that, or as close as possible to it.  By 
> contrast, you seem to suggest a change in the current behavior for 
> buffer text as well.

Which is why my proposal is to not break anything, but only to give 
applications the control of how what they insert in the minibuffer is 
displayed.  A start_display_at_beginning_of_minibuffer variable that would 
be reset in read_minibuf() and that an application could set in 
minibuffer-setup-hook.  I don't understand why you would be opposed to 
such a change.

> That may or may not be a good idea, but it's a separate issue, so should 
> be discussed separately

It's _not_ a separate issue, it's the issue at hand.

> (and in that separate discussion I will generally be opposed to the 
> change you are proposing, because we had the current behavior for many 
> years, and so changes like the one you propose run serious risk of 
> breaking expectations of some package out there).

Why would a change that does not change Emacs' behavior in any way except 
if the user requests it "run serious risk of breaking expectations of some 
package out there"?  It only gives application writers the freedom to 
decide what Emacs should do, which is IMO a good thing in general.