GNU bug report logs - #43519
28.0.50; Overlay at end of minibuf hides minibuf's real content

Previous Next

Full log

Message #215 received at 43519 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's
 real content
Date: Mon, 21 Sep 2020 19:37:21 +0000

>
> My summary of the problem raised by Stefan:
>
>  . icomplete is just an example that exhibits a more general issue
>  . the more general issue is that the display after resizing the
>    mini-window is different depending on whether it uses plain buffer
>    text or an after-string overlay at EOB
>

I don't understand how you came to understand things in that way, but this 
is neither the meaning of the bug title "Overlay at end of minibuf hides 
minibuf's real content" (real content = non-overlay part), nor what was 
discussed in emacs-devel.  A short summary:

Ergus: [To implement icomplete-vertical] we need to add the exact amount 
of lines as accurate as possible.

Stefan: I *strongly* recommend you design the behavior under the 
assumption that it's OK if there are a few more lines in the (mini)buffer 
than are actually visible.

Me: if there are too many candidates the prompt disappears, leaving the 
cursor at the beginning of the minibuffer, which is counterintuitive.  A 
simple example: after (setq max-mini-window-height 1), with "M-x a" the 
"M-x" prompt and the "a" disappear.

Stefan: That can (and should) be fixed without having to reduce the number 
of candidates inserted in the (mini)buffer.

Ergus: It will be great if you give me an idea about how to do that.

Stefan: You need to figure out why the redisplay decides to hide the 
prompt rather than some other part of the (mini)buffer.

Stefan files this bug.

Previous Next

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