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

Previous Next

Full log

Message #65 received at 43519 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's
 real content
Date: Mon, 21 Sep 2020 17:17:23 +0300

> Date: Mon, 21 Sep 2020 06:50:22 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 43519 <at> debbugs.gnu.org
> 
> It is "true that in all of these situations starting the mini-window display at BOB would DTRT", but it is also true that in all of these situations the height overflow is due to an overlay at EOB.

By "height overflow" you mean the fact that max-mini-window-height
screen lines aren't enough to display all of the stuff we want in the
mini-window?  If so, you are considering only a narrow class of use
cases.  In other use cases, we could have a very long prompt, for
example.  Or we could even have a tall enough image there.  Then
reasons for "overflow" could be different.

> So another solution, which I think would be even better, but might change the existing behavior marginally, would be to calculate the height two times, once at EOB and once at EOB-1.

This assumes that there's no overlay strings at EOB-1?  Why would we
assume something like that?  It again narrows the set of use cases
which will be handled properly.

It also seems to assume that the prompt (which ends at EOB) is much
shorter than the overlay string displayed beyond EOB.  But this is not
guaranteed: it could be the other way around, in which case the
proposed changes will not show the most important part of the
mini-window's display.

My suggestion is to go back to the "start display at BOB" assertion
(which is not true in general), and try to find a more general/more
accurate one.  For example: would it be okay to start the display at
the beginning of the screen line where we end up after
move_it_vertically_backward returns?  This way, if the prompt is very
long, we will start in its middle (at the beginning of one of the
continuation lines used to display the prompt), but we will show as
much of the overlay string as possible.  This strategy will also
handle minibuffer prompts that don't use overlay strings at all better
than if we start at BOB.

Previous Next

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