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]

> > 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.
>
> You should update your recipe, because Eli's patch takes care of this 
> case already.

Indeed, but this recipe is what exists in Emacs 27.1 and what most people 
can try immediately.  The "problem" with Eli's patch is that it takes care 
of 95% of the cases, and that the remaining 5% are more difficult to see, 
yet are there.

> I'm not completely sure which case(s) you're thinking of now that Eli's 
> patch handles the most common case we've seen so far.  But maybe the 
> problem shows up when we have a minibuffer content that spans 2 lines, 
> in which case the redisplay will choose to show the last line (assuming 
> point is in the second line) plus icomplete's overlay rather whereas you 
> presumably would want to see both lines from the minibuffer (and hence 
> one line less from icomplete's overlay)?

Yes.  See the recipe in my previous mail.  If works with N lines, with N > 
1.

> So a recipe could look something like:
>
>    src/emacs -Q --eval '(setq max-mini-window-height 2)' -f icomplete-mode
>    C-x C-f 
> lisp/progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../
>
> where we see the whole of icomplete's overlay rather than seeing the 
> whole of the minibuffer's actual content.

The problem is that such a recipe would only work with a not-too-wide 
Emacs frame and a not-too-small default font.  For example, on my 
computer, it does not demonstrate the problem.

> In general both are perfectly valid choices and which one is best 
> depends on what is the intention behind the particular overlay and its 
> relation to the minibuffer's content, so indeed the redisplay would need 
> additional information in order to decide which behavior to choose.

I agree with you, which is why I think that ATM the best thing to do is 
just to make such a choice possible.

> > 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).
>
> Currently, the redisplay code focuses on making sure point is displayed. 
> In the resize_mini_widow code we try to accommodate some extra desires, 
> mostly in the form of giving more importance either to what's before 
> point or what's after it.

I don't think this is precise enough, but OTOH it's very hard to precisely 
define what happens.  Currently resize_mini_window() sets "start" to 
max-mini-window-height lines before the end of the buffer (unless 
resize-mini-windows is nil, in which case "start" is set to BOB).  The 
redisplay code takes that value; if point is not between start and EOB it 
overrides it, otherwise it displays the buffer between start and EOB.

> > The attached patch does not change the behavior of Emacs in any way, 
> > unless the feature it introduces is used.
>
> I see the following potential problem with it: icomplete will likely 
> want to set it globally, but that means it will also affect uses of the 
> mini window where icomplete is not used.  Also, potential other users 
> may encounter similar difficulties.

No, if you look at the patch its value is reset to nil whenever the 
minibuffer is entered.  And the example I gave with icomplete is:

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

where icomplete-minibuffer-setup-hook is run during minibuffer setup if 
(and only if) icomplete is active.  So the behavior with M-: for example 
would not be affected.

> I don't have a patch to suggest, but I think ideally, I'd want clients 
> like icomplete to tell the redisplay either something like "please 
> display as much as possible of *this* chunk of text" or maybe "feel free 
> not to display all of this overlay, it's not super important".

Yes, that's the point.  The patch I proposed tells redisplay "please 
display as much as possible of the text between BOB and point", when the 
current behavior tells redisplay "please display as much as possible of 
the text between point and EOB".  Something more fine-grained would of 
course be possible, but I don't think it is a good idea to implement a 
feature when there is no clear need for it.