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

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Sat, 19 Sep 2020 17:55:02 UTC

Severity: normal

Found in version 28.0.50

Full log


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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43519 <at> debbugs.gnu.org
Subject: Re: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's
 real content
Date: Sat, 19 Sep 2020 15:42:12 -0400
>> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Date: Sat, 19 Sep 2020 13:54:13 -0400
>> 
>>     % src/emacs -Q --eval '(setq max-mini-window-height 1)' -f icomplete-mode
>>     M-x a
>> 
>> at this point, you should presumably not see the "M-x a" in your
>> minibuffer window but only something of the form "{rp | lign | ..."
>
> Seems like a bug in icomplete: it attempts to compute the maximum
> length of candidates to be displayed, but seems like it fails, because
> the single mini-window line is continued, with no ellipsis at the end
> of the visible line?

I disagree: icomplete merely added text after point via an overlay and
didn't do anything which explicitly justifies horizontal scrolling.

I suspect the problem is that point is right on the overlay, so in
a sense it's both before *and* after the "{...}" text.  Conceptually it
should be considered as being before (which is why the cursor is placed
on the `{`), and the redisplay somewhat agrees with it (because it
hides the end of "{...}" rather than its beginning) but not completely
since it scrolled the display even though the `{` was already visible
without it.

> The fact that it calls window-width with no arguments is one possible
> problem -- it assumes the default face's font.  But I think the
> problem is more prominent than just that.
>
> It should produce an overlay string that fits in the window, then the
> prompt will be visible.

That would merely work around the underlying problem (and as you know
it's wickedly difficult to construct a string which will have "just the
right size" to fit into the minibuffer window).

Maybe there's a good reason for the redisplay to behave this way, but if
that's the case we need some way for icomplete (and other similar cases)
to make it behave differently.


        Stefan





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.