bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

[Gregory Heytings via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> In fact these changes are, IMO, very regrettable, because they solve 
>> 95% of the problems that have been discussed in bug#24293, bug#39379, 
>> bug#43519 and bug#43572 (and perhaps others), and the remaining 5% will 
>> have to be solved another way (by text properties if that's what you 
>> agree on with Stefan).
>
> They solve the issue pointed out by Stefan in bug#43519.  That they, by 
> sheer luck, also solve some of the other issues is just that -- sheer 
> luck.  I don't claim and didn't intend to solve all the problems, in 
> particular the issue discussed in this bug report.  They are related, 
> but different issues.
>

There have been several misunderstandings in these discussions.  In 
bug#43519, Stefan pointed out an issue with a simple recipe to exhibit a 
more general problem.  This simple recipe, because it was simple, did not 
demonstrate all aspects of the problem.  In particular, it only 
demonstrated what he called "horizontal scrolling", when the problem in 
fact involves both horizontal _and vertical_ scrolling.

I'll remind a second time the discussion on emacs-devel that prompted 
Stefan to file bug#43519:

Ergus: [To implement icomplete-vertical] we need to add the exact amount 
of lines as accurate[ly] as possible.

Stefan: I *strongly* recommend you design the behavior under the 
assumption that it's OK if there are a few more lines in the (mini)buffer 
than are actually visible.

Me: If there are too many candidates the prompt disappears, leaving the 
cursor at the beginning of the minibuffer, which is counterintuitive.  A 
simple example: after (setq max-mini-window-height 1), with "M-x a" the 
"M-x" prompt and the "a" disappear.

Stefan: That can (and should) be fixed without having to reduce the number 
of candidates inserted in the (mini)buffer.

Ergus: It will be great if you give me an idea about how to do that.

Stefan: You need to figure out why the redisplay decides to hide the 
prompt rather than some other part of the (mini)buffer.

Stefan files bug#43519 (with the "M-x a" example).

As you see, the point is to keep the prompt visible, not just to avoid 
horizontal scrolling.  And Stefan refers to bug#24293 and bug#39379, where 
the same problem (the prompt becomes invisible) is explained and 
workarounds are discussed.

>> I don't think you will do this, but please, please: revert these 
>> changes.
>
> Reverting those changes would be a very strange thing to do.  Those 
> changes solve a specific problem, and they solve it cleanly.
>

They partially solve a specific problem.  This specific problem exists 
only in the context of inserting completion candidates at EOB with an 
overlay.  And the specific problem is not horizontal scrolling, the 
specific problem is the prompt that becomes invisible.  I clearly said 
(and explained) in bug#43519 that to solve that problem it is necessary to 
start display at BOB, and you preferred to implement a change that starts 
display at BOL.  I think these changes are misleading.