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>]

>
> And given the policy of displaying the last visible part, what would you 
> expect in this case?
>

I do not expect something else with the current policy, I suggest to add a 
new policy with whom the first part of the minibuffer would be displayed 
instead of its last part.

>>> How will Lisp programs decide when to set this flag and when not to 
>>> set it?  What would be the criteria?
>>
>> The criteria is simply: should the prompt and user input be displayed?
>
> How do you decide that?
>

I gave a simple and clear example of an implementation of vertical 
icomplete, which demonstrates how this feature would be used:

(setq icomplete-separator "\n")
(add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t)))

Please try it (together with my patch), you'll see what I mean.

With the current behavior (with (setq icomplete-separator "\n")), whenever 
the prompt and user input are larger than the width of Emacs' frame and 
there are too many completion candidates, the prompt and user input 
disappear, and when there are only a few completion candidates the prompt 
and user input re-appear.

With this patch the prompt and user input are always visible, and as many 
completion candidates as possible (given max-mini-window-height) are 
displayed after them.

>
> Or let me ask it differently: when will a program decide that it wants 
> the current behavior of perhaps NOT showing the prompt, if the 
> mini-window is not large enough?
>

In the use case of completion candidates displayed after point with an 
overlay at EOB, the answer is simple: never.  If at some point it becomes 
impossible to display the prompt, say because max-mini-window-height 
equals 1 and the prompt and user input are larger than the width of the 
Emacs frame, redisplay will hide the prompt, and that's fine.  As you 
said: "Displaying long stuff in a mini-window that is forced to be small 
will always present some problems, no matter what we do."

>> Doing this automatically (that is, unconditionally) would have the 
>> consequence that when point reaches the last line of the minibuffer 
>> (that is, the max-mini-window-height's line), the mini-buffer would be 
>> recentered, and the topmost lines would be hidden.
>
> What resize_mini_window does ensures that recentering doesn't happen. 
> That is why it sets w->start: it's an indication to the display engine 
> to obey that window-start position if point is visible with it.
>
> So you are trying to solve a case that doesn't need to be solved.
>

I'm not trying to solve any problem here.  You said: "If you are saying 
that any Lisp program that reads from the minibuffer will want that, then 
(assuming that others agree), it would be better to do this automatically 
in the display code."  I answered this by saying: "This is not what I'm 
saying, and I would not dare to make such a general judgment.  I only 
claim that it is better to make this possible.  There is at least one case 
where I think it is better not to do this automatically."  And I explained 
that case.

>>> Binding the variable inside the minibuffer-setup-hook will affect all 
>>> the subsequent calls to resize_mini_window, until the next call to 
>>> read-from-minibuffer resets it, which may not be what the Lisp program 
>>> wants, and could have unintended consequences.
>>
>> I can't think of such unintended consequences.  In the use case of 
>> displaying completion candidates, this (the fact that it affects all 
>> successive calls to resize_mini_window) is indeed what is wanted.
>
> Well, I _can_ think of such consequences.  As I said, resize_mini_window 
> is called in many situations that don't involve completion, so setting 
> that variable to affect all of them is a bad idea.  We need something 
> more fine-grained if we want to implement such a feature.
>

It would be very helpful if you could clarify what the consequences you 
think of are.