GNU bug report logs - #24293
25.1; Display bug: icomplete prompt not visible with icomplete-separator "\n"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24293 in the body.
You can then email your comments to 24293 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: 25.1;
 Display bug: icomplete prompt not visible with icomplete-separator
 "\n"
Date: Tue, 23 Aug 2016 17:44:12 +0200

Hello,

In emacs -Q, eval

  (setq icomplete-separator "\n")

and do

  M-x icomplete-mode <return>

Then, e.g.

  M-x m

The icomplete minibuffer prompt is invisible (bug).

But you see that it's "there" when you hit <left>.  And changing the
value of `resize-mini-windows' to nil makes the issue disappear - so I
think this is caused by a problem in the display code.


Thanks in advance,

Michael.




In GNU Emacs 25.1.3 (x86_64-pc-linux-gnu, GTK+ Version 3.20.7)
 of 2016-08-20 built on drachen
Repository revision: e7cf48d52c2c06809e1a8d1f9acd670f78d43c47
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description:	Debian GNU/Linux testing (stretch)

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY
LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_ALL: de_DE.utf8
  value of $LC_COLLATE: C
  value of $LC_TIME: C
  value of $LANG: de_DE.utf8
  locale-coding-system: utf-8-unix

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 24293 <at> debbugs.gnu.org
Subject: Re: 25.1;
 Display bug: icomplete prompt not visible with icomplete-separator
 "\n"
Date: Tue, 23 Aug 2016 19:18:48 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>
> Date: Tue, 23 Aug 2016 17:44:12 +0200
> 
> In emacs -Q, eval
> 
>   (setq icomplete-separator "\n")
> 
> and do
> 
>   M-x icomplete-mode <return>
> 
> Then, e.g.
> 
>   M-x m
> 
> The icomplete minibuffer prompt is invisible (bug).
> 
> But you see that it's "there" when you hit <left>.  And changing the
> value of `resize-mini-windows' to nil makes the issue disappear - so I
> think this is caused by a problem in the display code.

Surprisingly, stepping through the code with a debugger reveals that
this is not a bug, but (almost) deliberate behavior.  Set
max-mini-window-height to 0.9, and you will see the entire prompt.

The default value of that variable is 0.25, so Emacs doesn't resize
mini-windows to more than 1/4th of the height of the frame's root
window.  And the height required to show the prompt is much larger in
this case.  So the mini-window is only resized to 9 lines, and Emacs
then attempts to show the last part of the minibuffer text that fits
in the mini-window.  You can see this in action if you evaluate this:

  (message "1\n2\n3\n4\n5\n6\n7\n8\n9\n0\n1\n")

What happens next is that the after-string causes the display to start
at the beginning of the string, because Emacs cannot start the
window's display in the middle of an overlay string.  So what is
actually shown is not the end, but the middle of the overlay string.

Not sure what, if anything, to do with this.  IMO, in this situation
showing anything at all will not serve the user well enough, so I tend
to do nothing and argue that displaying minibuffer text that requires
so many lines cannot possibly work well anyway, and when the text ends
with a multi-line overlay string, we hit a limitation of the display
engine.

Thanks.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24293 <at> debbugs.gnu.org
Subject: Re: bug#24293: 25.1;
 Display bug: icomplete prompt not visible with icomplete-separator
 "\n"
Date: Tue, 23 Aug 2016 21:06:11 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> What happens next is that the after-string causes the display to start
> at the beginning of the string, because Emacs cannot start the
> window's display in the middle of an overlay string.  So what is
> actually shown is not the end, but the middle of the overlay string.

Ok, it's probably not worth trying to change the display engine for
this.

Maybe we can fix it in icomplete instead.  AFAIK icomplete tries to
limit the number of shown candidates according to some settings like
maximum number of lines to display, but doesn't handle the case of a
separator including a newline character correctly.

Is it possible to determine reliably the number of lines a minibuffer
window can display maximally for given max-mini-window-height?


Michael.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 24293 <at> debbugs.gnu.org
Subject: RE: bug#24293: 25.1; Display bug: icomplete prompt not visible with
 icomplete-separator "\n"
Date: Tue, 23 Aug 2016 12:38:00 -0700 (PDT)

> Maybe we can fix it in icomplete instead.  AFAIK icomplete tries to
> limit the number of shown candidates according to some settings like
> maximum number of lines to display, but doesn't handle the case of a
> separator including a newline character correctly.
> 
> Is it possible to determine reliably the number of lines a minibuffer
> window can display maximally for given max-mini-window-height?

1. Please take care not to break the case of a standalone minibuffer
frame, or any other context where the minibuffer can be resized to
accommodate a large number of icomplete candidates.

IOW, a newline separator is not a problem at all in some contexts.
Please don't limit or break that behavior.  Thx.

2. It's not clear to me why this should be handled in icomplete.el.
Doesn't the same problem arise if multi-line text is inserted in
the minibuffer or if any other program does something similar to
what icomplete does?  IOW, isn't it a general problem, which would
call for a general solution?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: michael_heerdegen <at> web.de, 24293 <at> debbugs.gnu.org
Subject: Re: bug#24293: 25.1; Display bug: icomplete prompt not visible with
 icomplete-separator "\n"
Date: Wed, 24 Aug 2016 05:44:45 +0300

> Date: Tue, 23 Aug 2016 12:38:00 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 24293 <at> debbugs.gnu.org
> 
> 1. Please take care not to break the case of a standalone minibuffer
> frame, or any other context where the minibuffer can be resized to
> accommodate a large number of icomplete candidates.

This is not relevant for such mini-windows.

> 2. It's not clear to me why this should be handled in icomplete.el.
> Doesn't the same problem arise if multi-line text is inserted in
> the minibuffer or if any other program does something similar to
> what icomplete does?  IOW, isn't it a general problem, which would
> call for a general solution?

No.  See the example I posted up-thread.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 24293 <at> debbugs.gnu.org
Subject: Re: bug#24293: 25.1;
 Display bug: icomplete prompt not visible with icomplete-separator
 "\n"
Date: Wed, 24 Aug 2016 05:47:40 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: 24293 <at> debbugs.gnu.org
> Date: Tue, 23 Aug 2016 21:06:11 +0200
> 
> Is it possible to determine reliably the number of lines a minibuffer
> window can display maximally for given max-mini-window-height?

For a non-minibuffer frames, the calculations are in
resize_mini_window.  They are quite simple, but if something there is
not clear, please ask.  The documentation of max-mini-window-height in
the ELisp manual can also help.

Note that the calculations in resize_mini_window are in pixels, and a
"line height" is interpreted in terms of the frame's canonical
character height.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 24293 <at> debbugs.gnu.org
Subject: Re: bug#24293: 25.1; Display bug: icomplete prompt not visible with
 icomplete-separator "\n"
Date: Wed, 24 Aug 2016 11:08:01 +0200

> Is it possible to determine reliably the number of lines a minibuffer
> window can display maximally for given max-mini-window-height?

For ‘max-mini-window-height’ specified as float you can get its maximum
theoretical pixel height by multiplying ‘max-mini-window-height’ with
the sum of the pixel heights of the frame's root window and the frame's
minibuffer window.  The real height is also constrained by the fact that
the height of the root window must not drop below the value returned by
‘window-min-pixel-height’ for that window.  Get the line value by
rounding to the pessimistic side respectively.  If you come up with a
good function, we can install it as say ‘window-max-mini-window-height’.

martin

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, 24293 <at> debbugs.gnu.org
Subject: Re: bug#24293: 25.1; Display bug: icomplete prompt not visible with
 icomplete-separator "\n"
Date: Sun, 5 Apr 2020 15:42:10 +0300

FWIW, somebody published a nicely-working icomplete-vertical-mode recently:

https://github.com/oantolin/icomplete-vertical

According to the author, it deals with this particular problem with a 
combination of (setq truncate-lines t) and an enlarge-window call: 
https://www.reddit.com/r/emacs/comments/fswt7c/using_icomplete_vertically/fm8z6h0/

The only downside to this mode I could find is that it keeps the 
minibuffer fixed height (the max prospects count plus 1). But it can be 
considered an upside as well, matter of taste.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, 24293 <at> debbugs.gnu.org
Subject: Re: bug#24293: 25.1; Display bug: icomplete prompt not visible with
 icomplete-separator "\n"
Date: Sun, 5 Apr 2020 15:56:14 +0300

On 05.04.2020 15:42, Dmitry Gutov wrote:
> The only downside to this mode I could find is that it keeps the 
> minibuffer fixed height (the max prospects count plus 1). But it can be 
> considered an upside as well, matter of taste.

And this is actually false. If grow-mini-windows is t, it shrinks the 
minibuffer as appropriate using an enlarge-window call in an advice.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 24293 <at> debbugs.gnu.org
Subject: Re: bug#24293: 25.1; Display bug: icomplete prompt not visible with
 icomplete-separator "\n"
Date: Sat, 19 Sep 2020 13:47:12 -0400

>> In emacs -Q, eval
>> 
>>   (setq icomplete-separator "\n")
>> 
>> and do
>> 
>>   M-x icomplete-mode <return>
>> 
>> Then, e.g.
>> 
>>   M-x m
>> 
>> The icomplete minibuffer prompt is invisible (bug).
>> 
>> But you see that it's "there" when you hit <left>.  And changing the
>> value of `resize-mini-windows' to nil makes the issue disappear - so I
>> think this is caused by a problem in the display code.
>
> Surprisingly, stepping through the code with a debugger reveals that
> this is not a bug, but (almost) deliberate behavior.  Set
> max-mini-window-height to 0.9, and you will see the entire prompt.

The "prompt" in the above example is not the whole text shown in the
minibuffer but just "M-x m".

> The default value of that variable is 0.25, so Emacs doesn't resize
> mini-windows to more than 1/4th of the height of the frame's root
> window.  And the height required to show the prompt is much larger in
> this case.

No, a single line is sufficient to show "the prompt".


        Stefan

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 24293 <at> debbugs.gnu.org
Subject: Re: bug#24293: 25.1; Display bug: icomplete prompt not visible with
 icomplete-separator "\n"
Date: Fri, 04 Dec 2020 12:08:52 +0100

[Message part 1 (text/plain, inline)]

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> In emacs -Q, eval
>
>   (setq icomplete-separator "\n")
>
> and do
>
>   M-x icomplete-mode <return>
>
> Then, e.g.
>
>   M-x m
>
> The icomplete minibuffer prompt is invisible (bug).

On the current trunk, I get:

[Message part 2 (image/png, inline)]

[Message part 3 (text/plain, inline)]

The M-x (is that what you mean by "the icomplete minibuffer prompt?") is
shown, so has this been fixed recently?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #40 received at 24293-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 24293-done <at> debbugs.gnu.org
Subject: Re: bug#24293: 25.1; Display bug: icomplete prompt not visible with
 icomplete-separator "\n"
Date: Tue, 08 Dec 2020 01:08:45 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> The M-x (is that what you mean by "the icomplete minibuffer prompt?")
> is shown, so has this been fixed recently?

You interpreted correctly.  Yes, seems indeed the issue has disappeared.

AFAIR the problem had been that the first line had been hidden when
resizing the mini window, which means it must not have been a bug in
icomplete, rather a display thing.  [ The next time I'll also attach a
screen shot, that would make things simpler. ]

Good - closing.


Thanks,

Michael.

Previous Next

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