GNU bug report logs - #43519
28.0.50; Overlay at end of minibuf hides minibuf's real content

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <ghe <at> sdf.org>
Cc: monnier <at> iro.umontreal.ca, 43519 <at> debbugs.gnu.org
Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content
Date: Mon, 21 Sep 2020 17:02:27 +0300

> Date: Sun, 20 Sep 2020 21:04:02 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 43519 <at> debbugs.gnu.org
> 
> It is difficult to fix such problems on the application level. If the stuff to be displayed in the mini-window fits the mini-window after resizing it to max-mini-window-height, the problem does not happen indeed. But the difficulty is precisely to create the stuff to be displayed in such a way that it fits the mini-window, because it can use a font that is not the default one, it can have embedded newlines, it can contain lines that are too wide for the mini-window, and so forth.

I believe using window-text-pixel-size (which I already mentioned
several times) will avoid any such difficulties, since that function
takes all of those complications into account.  Therefore, I still
don't understand why this approach is not being explored more
actively.

> it is true that in all of these situations starting the mini-window display at BOB would do the right thing.

Are you sure?  What if the prompt is longer than a screen line (i.e.,
the prompt itself is continued on the 2nd and subsequent screen
lines)?  If the prompt is long, but the list of candidates is short,
starting the mini-window display at BOB might fail to show some or all
of the candidates, because the long prompt uses up most or all of the
mini-window screen estate.

>     IOW, the basic logic is to show the last max-mini-window-height screen lines of what's in mini-window.
> 
> Yes, and this is not desirable in certain cases, it should be possible to show the *first* max-mini-window-height screen lines of what's in mini-window. 

Showing the last part is in general a better strategy in the use cases
relevant to the mini-window, which are about user interaction.  I
believe you assume that starting at BOB still shows enough of the text
to allow the user to interact intelligently, but those are not the
only cases we should keep in mind, since the prompt doesn't have to be
short enough for that assumption to be true.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.