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]

Ping!

> Date: Thu, 24 Sep 2020 19:54:36 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: ghe@sdf.org, 43572@debbugs.gnu.org
> 
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Gregory Heytings <ghe@sdf.org>,  43572@debbugs.gnu.org
> > Date: Thu, 24 Sep 2020 12:40:59 -0400
> > 
> > > So I agree with Stefan that the text inserted into the minibuffer
> > > should itself indicate to the display engine that it wants to be
> > > displayed starting at BOB.  That way we don't have to worry about
> > > inadvertently affecting other users of the mini-window.
> > 
> > It might be difficult/inconvenient to have the info directly in the
> > text, tho.
> 
> I don't think I see why it would be difficult/inconvenient.  Can you
> explain?
> 
> > How 'bout using a window-parameter whose value should be an overlay
> > indicating the "area of focus", and then only obey this parameter if:
> > - the overlay is in the buffer that's being displayed.
> > - and window-point is lies within this overlay.
> 
> This sounds like the same idea of a text property, only with an
> overlay and a more complicated test for applicability.  When I said
> "text property", I meant both text and overlay property, so if you
> think your proposal above is less difficult/inconvenient, then using
> just an overlay would be even simpler, no?  Or what am I missing?
> 
> > One more thing: there's a good argument to make that icomplete-vertical
> > should list the completions *above* the minibuffer's prompt rather than
> > below (so as not to affect the positions of the minibuffer's prompt so
> > much).  But in that case, the part of the overlay's after/before string
> > (when too long) which should be truncated (when the mini-window is too
> > small) is the beginning, whereas IIUC the current redisplay is unable to
> > display "the end" of an overlay's after/before string unless it also
> > shows its beginning.
> 
> Yes, we cannot start a window's display in the middle of an overlay
> string.
> 
> In general, display and overlay strings were not intended for 75%
> (maybe more) of the uses they get nowadays, and it shows.