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: Gregory Heytings <ghe <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.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 14:18:07 +0000

>
> 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.
>

This I don't know or understand either.  My guess is that creating a 
candidate list by adding one candidate at a time and checking with 
window-text-pixel-size if the result is too large would be inefficient. 
This could be improved with a kind of binary search of course.

>> 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.
>

Yes I'm sure.  In the case you mention indeed some candidates will not be 
displayed, but that's not a problem because most of the time all 
candidates are not displayed anyway.  Of course there is the case when the 
prompt is, say, two characters less than the mini-window width, in which 
case no candidates will be displayed (if the user has (setq 
max-mini-window-width 1)), but this is unlikely to happen, and the default 
value of max-mini-window-width is 0.25 anyway.

>>> 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.
>

In general yes, but not when displaying completion candidates with an 
overlay at EOB, with the point before the overlay text.  In that case you 
start with a blinking cursor at the top left of the minibuffer, without 
any indication of what you are doing or should do.

>
> 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.
>

I tested this, and it works, even with overlong prompts.  In that case 
(for example with (setq max-mini-window-width 1) and a prompt wider than 
the mini-window width) the prompt disappears, but this is expected, and 
it's a corner case that almost never happens.  Moreover when displaying 
completion candidates you don't start with a long prompt (except, again, 
in corner cases).

Previous Next

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