|
From: | Gregory Heytings |
Subject: | bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content |
Date: | Sun, 20 Sep 2020 21:04:02 +0000 |
User-agent: | Alpine 2.22 (NEB 394 2020-01-19) |
For some reason I did not receive a copy of your mail. I see it now.
. Fix these problems on the application level. In the case in point, that would mean for icomplete.el to augment its calculations of where to truncate the list of candidates so that the problem doesn't happen (and AFAICT it doesn't happen if the stuff to be displayed in the mini-window fits the mini-window after resizing it to max-mini-window-height).
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.
. Define in more detail what situations we would like to fix in the display code, so that we could install special ad-hoc changes there to handle those situations. For example: is it true that in all of these situations starting the mini-window display at BOB would DTRT? If so, I think this could be arranged. If not, why not, and what is the more correct definition of the situations we want to handle?
See my proposal, which does exactly this. Yes, it is true that in all of these situations starting the mini-window display at BOB would do the right thing.
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.
[Prev in Thread] | Current Thread | [Next in Thread] |