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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <ghe <at> sdf.org>
Cc: 43519 <at> debbugs.gnu.org
Subject: Re: bug#43519: (no subject)
Date: Sun, 20 Sep 2020 09:08:52 +0300

> Date: Sun, 20 Sep 2020 01:00:54 +0000
> From: Gregory Heytings via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> A short note, which could perhaps be useful: this behavior does not only 
> happen when the overlay text is too wide for the minibuffer width (in 
> which case it perhaps could be argued that the display engine tries to do 
> something appropriate).
> 
> 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?

> 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).

Previous Next

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