bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real conte


From: Eli Zaretskii
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@sdf.org>
> cc: Stefan Monnier <monnier@iro.umontreal.ca>, 43519@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]