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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 22 Sep 2020 20:57:13 +0000
> From: Gregory Heytings via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> In Emacs 27.1, the mini-window displays the last lines of the minibuffer.
> 
> This is, in general, the desired behavior, but in some cases it is not.
> 
> One case in which this behavior is not desirable is when completion 
> candidates are displayed with an overlay at the end of the buffer.  When 
> this overlay is taller than max-mini-window-height, the prompt and the 
> user input so far disappear.  A simple example: M-: (setq 
> max-mini-window-height 1), M-x icomplete-mode, M-x a.

Actually, on the current master this example does show the "M-x a"
part.

> This feature request follows the discussion in bug#43519.  The change 
> proposed there by Eli Zaretskii improves the behavior w.r.t. Emacs 27.1, 
> but it is still suboptimal to display completion candidates in a 
> user-friendly way.  For example:
> 
> Find file: <user input>|
> <completion candidates>
> 
> (where | represents the cursor) will become:
> 
> <user input>|
> <completion candidates>
> 
> when the user input becomes larger than a line.  That is, the "Find file:" 
> prompt and the user input on the first line will disappear.

I suggest to show a recipe for this, because the few I tried failed to
produce the described effect (with the current master).  Maybe I'm
missing something.

> The attached patch makes it possible to (selectively) choose to display 
> the _first_ lines of the minibuffer instead of its _last_ lines (which is 
> and remains the default behavior).  This means that displaying completion 
> candidates becomes a trivial task: it suffices to create an overlay with 
> completion candidates, without worrying at all about its size (or about 
> the size of the prompt and user input), and as many of these candidates as 
> possible will automatically be displayed.
> 
> For example, implementing vertical icomplete only requires:
> 
> (setq icomplete-separator "\n")
> (add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t)))

I have a couple of comments regarding the proposed change:

 . How will Lisp programs decide when to set this flag and when not to
   set it?  What would be the criteria?  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.

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