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 15:26:25 +0000

>
> But with long enough prompt, you can have _none_ of the candidates 
> displayed.
>

With a long enough prompt *and* a small enough mini-window, yes, this can 
happen.

>
> "Unlikely to happen" is not a good guideline for making changes in the 
> display code, IME.  Guess what? most of the things I considered 
> "unlikely" did happen eventually.
>

I'm not saying it will not happen, in fact it's easy to make it happen. 
Just create a long enough directory name, (setq max-mini-window-height 1), 
and enter that directory.  I'm just saying that the likelihook it will 
happen is practice is much, much smaller than the other case, where users 
want to see the prompt, what they have typed so far, and some completion 
candidates after the point.

>
> So I prefer a more generally correct solution, especially when it's not 
> hard to implement.
>

I fear it will be hard to find a "more generally correct solution".  In 
fact, it's a correct solution, so you are looking for a "more generally 
_more_ correct solution" ;-)  BTW, the current solution does not claim to 
be a correct solution, but only that it "seems desirable generally".

>> 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.
>
> Are you talking about what we see today?
>

Yes.

>
> I'm not arguing to leave it unchanged, I'm talking about what would be 
> the better solution, and starting always at BOB sounds sub-optimal to 
> me.
>

I can't think of a better solution.

>
> The solution I proposed in my other message (assuming that it is 
> accepted) is more general, I think.
>

If you mean "to start the display at the beginning of the screen line 
where we end up after move_it_vertically_backward returns", it is IMO 
worse.  At least with the usecase of completion candidates in mind, it is 
better to have one or two less candidates at the bottom of the 
mini-window, and the prompt displayed at the top of the mini-window.

>
> It also covers "corner cases" which you are willing to disregard.
>

I do not disregard them.  I tested them.  The worst that could happen is 
that, in some rare cases, no completion candidates would be displayed in 
the mini-window, in which case the user can hit TAB and they will be 
displayed in a *Completions* buffer.

Previous Next

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