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: Wed, 23 Sep 2020 19:15:40 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: 43572@debbugs.gnu.org
> 
> I just tested this again with current master, and actually the result is 
> slighly worse than what I though, when the prompt and user input becomes 
> larger than a line you don't see:
> 
> <user input>|
> <completion candidates>
> 
> but:
> 
> |<completion candidates>
> 
> (IOW the characters at the beginning of the Nth line, with N > 1, 
> disappear.)
> 
> Again it's difficult to give a simple recipe, because it depends on the 
> width of your Emacs frame and of the size of the font used in the 
> mini-window.  The simplest recipe I can think of is:
> 
> 1. create a "long enough" directory name, with say ten subdirectories
> 2. emacs -Q
> 3. make the frame width "small enough"
> 4. M-: (setq max-mini-window-height 5)
> 5. M-x icomplete-mode
> 6. M-: (setq icomplete-separator "\n")
> 7. C-x C-f and enter the "long enough" directory name
> 
> What you will see at this point is:
> 
> |{<completion candidate 1>
> <completion candidate 2>
> ...
> <completion candidate 5>

Is this worse than before the change?

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

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

> (A more precise way to formulate that criteria would be: should the prompt 
> and user input be displayed, unless it is impossible to display them?)

We are discussing the case when it's impossible to display both; the
case when it's possible is easy and is already handled.

> There is at least one case where I think it is better not to do this 
> automatically.  As Stefan indicated in bug#43519, with M-:, when you input 
> data, the current behavior is to always have point on the last line of the 
> minibuffer.

That case doesn't need any special handling in resize_mini_window,
because the display engine will always make sure point is visible.  If
the window-start point determined by resize_mini_window doesn't allow
point to be visible, the display engine will find another
window-start, which would.

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

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