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

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

[Michael Heerdegen]

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

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

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Eli Zaretskii <eliz@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.

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

[Michael Heerdegen]

Eli Zaretskii <eliz@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.

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

[Drew Adams]

> 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?

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

[Eli Zaretskii]

> Date: Tue, 23 Aug 2016 12:38:00 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 24293@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.

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

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 24293@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.

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

[martin rudalics]

 > 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

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

[Stefan Monnier]

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

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

[Dmitry Gutov]

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.

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

[Dmitry Gutov]

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.

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

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

Michael Heerdegen <michael_heerdegen@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:


[-- Attachment #2: Type: image/png, Size: 14311 bytes --]

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]


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

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

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@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.