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: Gregory Heytings
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
User-agent: Alpine 2.22 (NEB 394 2020-01-19)



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.





reply via email to

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