GNU bug report logs -
#43519
28.0.50; Overlay at end of minibuf hides minibuf's real content
Previous Next
Full log
Message #80 received at 43519 <at> debbugs.gnu.org (full text, mbox):
>> 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?
>
Yes.
>
> 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.
>
I already commented the case of a very long prompt. For a tall enough
image, I don't know.
>
>> 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.
>
The problem happens when completion candidates (with icomplete, ido, and I
guess others are doing the same) are displayed after the point, with an
overlay at EOB. If you think this is a too narrow set of use cases, I
guess the best thing to do is to let applications choose what to do with a
start_display_at_beginning_of_minibuffer variable, to let applications
override what "seems desirable generally". Setting a variable in
minibuffer-setup-hook is easy.
>
> 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.
>
Did you look at what the code currently does? With emacs -q, M-x
icomplete-mode, (setq icomplete-separator "\n"), C-x C-f, you have a
mini-window with a blinking cursor at the top left, and each time you
enter a directory its name disappears. This behavior is considered not
user-friendly, so much that those who implement completion mechanisms use
complicated workarounds to avoid it.
>
> 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?
>
IMO, no, this would not be okay, at least not for icomplete/ido/... What
users expect is to see the prompt and what they have entered so far until
they press RET. Even if that means displaying one less completion
candidate at the end of the list. (When use complete a file name or a
command in a terminal, the prompt and what you have typed so far does not
disappear.)
>
> 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.
>
I see what you mean. So I propose to simply let applications/users choose
what they want in each case with a
start_display_at_beginning_of_minibuffer variable.
This bug report was last modified 4 years and 267 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.