GNU bug report logs -
#43519
28.0.50; Overlay at end of minibuf hides minibuf's real content
Previous Next
Full log
Message #26 received at 43519 <at> debbugs.gnu.org (full text, mbox):
>> For example, with (setq icomplete-separator "\n"), after M-x a the
>> contents of the minibuffer is displayed as follows:
>>
>> {rp
>> lign
>> propos
>> sm-mode
>> <... other candidates, one on each line>
>
> Does the entire list of candidates fit in the (enlarged) mini-window in
> that case? or are some of the candidates not displayed due to lack of
> space?
>
The list of candidates is in this case (with emacs -Q) 32 lines long
("{rp" on the first line, ... "...}" on the last line). With (setq
max-mini-window-height 32) the M-x prompt is displayed, with (setq
max-mini-window-height 31) it isn't.
But the point is that there is clearly enough horizontal space, so there
is (or there does not seem to be) no reason to scroll horizontally.
>> After pressing C-b (or <left>), the prompt becomes visible, and the
>> minibuffer is displayed as follows:
>
> C-b moves point from EOB to a character before EOB, thus the difference
> (AFAIR).
>
Yes, I know what C-b does, what I find surprising (but perhaps it is not,
I'm not an expert) is that only one line (the one with the prompt) is
scrolled horizontally.
[taken from emacs-devel:]
>
> You are asking the display engine to do the impossible.
>
No. With a minibuffer-only frame, the bug is not present. Whatever the
value of icomplete-separator (that is, with either a horizontal or
vertical list of candidates), you do see the "M-x" prompt and the
characters typed so far, even with (setq max-mini-window-height 1) and a
one line minibuffer. So it's feasible, and the display engine knows how
to do it.
This bug report was last modified 4 years and 266 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.