resize_mini_window question

resize_mini_window question

[Ergus]

Hi Eli:

As you know I have been working in icomplete-vertical and I just
received an issue that has to do with resize_mini_window function more
than with icomplete.

They are related with this bugs:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24293
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39379

The problem to me seems that the function xdisp.c:resize_mini_window
uses FRAME_LINE_HEIGHT(f); to resize; but in the report the user sets a
different font for the minibuffer. So when it sets
Vmax_mini_window_height to an int

Vmax_mini_window_height * unit is a "wrong" value and the lines will not
fit.

I see 3 possible clean solutions:

1) Modify resize_mini_window to use the minibuffer's font size to
calculate the height when Vmax_mini_window_height is an int. (don't know
if it is possible to access the minibuffer font size from there or if
this could produce some undesired side effect)

2) Modify the documentation of max-mini-window-height to specify that if
an integer, it specifies a number of lines respecting to the frame's
default font, not the minibuffer's visible lines.

3) Just force the text to fit ignoring that the number of real visible
lines will be different than max-mini-window-height. (This will be seen
as ignoring the max-mini-window-height)

What do you think is better?
Best,
Ergus

Re: resize_mini_window question

[Stefan Monnier]

> I see 3 possible clean solutions:
>
> 1) Modify resize_mini_window to use the minibuffer's font size to
> calculate the height when Vmax_mini_window_height is an int. (don't know
> if it is possible to access the minibuffer font size from there or if
> this could produce some undesired side effect)

I don't think this will work reliably, e.g. even if your minibuffer only
has N lines of text, line wrapping different fonts used for different
scripts, plus overlays and text-properties applied to specific parts of
the minibuffer's content will make that computation fail to give the
desired result.

> 3) Just force the text to fit ignoring that the number of real visible
> lines will be different than max-mini-window-height.

It might not even be possible anyway if the minibuffer's content uses up
more space than available in the frame.

> (This will be seen as ignoring the max-mini-window-height)

Indeed, which is another problem with this option.

> 2) Modify the documentation of max-mini-window-height to specify that if
> an integer, it specifies a number of lines respecting to the frame's
> default font, not the minibuffer's visible lines.

That sounds good.  It's not sufficient to fix the problem in
`icomplete-vertical` obviously, so `icomplete-vertical` would need to
be changed.  Maybe it could check the `window-end` to detect when the
minibuffer's content is larger than what fits and shorten
it accordingly?


        Stefan

Re: resize_mini_window question

[Ergus]

On Fri, Sep 18, 2020 at 11:30:58AM -0400, Stefan Monnier wrote:
>> I see 3 possible clean solutions:
>>
>> 1) Modify resize_mini_window to use the minibuffer's font size to
>> calculate the height when Vmax_mini_window_height is an int. (don't know
>> if it is possible to access the minibuffer font size from there or if
>> this could produce some undesired side effect)
>
>I don't think this will work reliably, e.g. even if your minibuffer only
>has N lines of text, line wrapping different fonts used for different
>scripts, plus overlays and text-properties applied to specific parts of
>the minibuffer's content will make that computation fail to give the
>desired result.
>
I think that in minibuffer this is not the most frequent case but I get
your point.

At least if we do check buffer-face-mode-remapping from C could give a
more accurate value. But maybe it doesn't worth it.

>> 3) Just force the text to fit ignoring that the number of real visible
>> lines will be different than max-mini-window-height.
>
>It might not even be possible anyway if the minibuffer's content uses up
>more space than available in the frame.
>
>> (This will be seen as ignoring the max-mini-window-height)
>
>Indeed, which is another problem with this option.
>
>> 2) Modify the documentation of max-mini-window-height to specify that if
>> an integer, it specifies a number of lines respecting to the frame's
>> default font, not the minibuffer's visible lines.
>
>That sounds good.  It's not sufficient to fix the problem in
>`icomplete-vertical` obviously, so `icomplete-vertical` would need to
>be changed.  Maybe it could check the `window-end` to detect when the
>minibuffer's content is larger than what fits and shorten
>it accordingly?
>
>
Yes I know. The problem with this was that in my case the user could be
expecting to see as many lines as specified in max-mini-window-height as
an integer.

The external package used to force an enlarge-window but I feel that
this is somehow a workaround.
>
>        Stefan
>

Re: resize_mini_window question

[Stefan Monnier]

> Yes I know.  The problem with this was that in my case the user could be
> expecting to see as many lines as specified in max-mini-window-height as
> an integer.

I think that is simply a problem of wrong expectations, which we could
somewhat fix by tweaking the documentation like you suggested.

> The external package used to force an enlarge-window but I feel that
> this is somehow a workaround.

Indeed.  I think it's important to find a solution to the
"disappearing prompt" that doesn't involve this since enlarging the
window is not always an option either.


        Stefan

Re: resize_mini_window question

[Ergus]

On Fri, Sep 18, 2020 at 12:02:13PM -0400, Stefan Monnier wrote:
>> Yes I know.  The problem with this was that in my case the user could be
>> expecting to see as many lines as specified in max-mini-window-height as
>> an integer.
>
>I think that is simply a problem of wrong expectations, which we could
>somewhat fix by tweaking the documentation like you suggested.
>
Maybe:

   DEFVAR_LISP ("max-mini-window-height", Vmax_mini_window_height,
     doc: /* Maximum height for resizing mini-windows (the minibuffer and the echo area).
If a float, it specifies a fraction of the mini-window frame's height.
If an integer, it specifies a number of lines with the frame's default char
height.  */);
   Vmax_mini_window_height = make_float (0.25);

>> The external package used to force an enlarge-window but I feel that
>> this is somehow a workaround.
>
>Indeed.  I think it's important to find a solution to the
>"disappearing prompt" that doesn't involve this since enlarging the
>window is not always an option either.
>
>
I already solved it in icomplete then. If we assume that the problem is
the wrong expectations then the solution is trivial with the current
changes in icomplete.

Best,
Ergus

Re: resize_mini_window question

[Stefan Monnier]

>   DEFVAR_LISP ("max-mini-window-height", Vmax_mini_window_height,
>     doc: /* Maximum height for resizing mini-windows (the minibuffer and the echo area).
> If a float, it specifies a fraction of the mini-window frame's height.
> If an integer, it specifies a number of lines with the frame's default char
> height.  */);
>   Vmax_mini_window_height = make_float (0.25);

LGTM, thanks.

> I already solved it in icomplete then. If we assume that the problem is
> the wrong expectations then the solution is trivial with the current
> changes in icomplete.

Even better,


        Stefan

Re: resize_mini_window question

[Eli Zaretskii]

> Date: Fri, 18 Sep 2020 17:01:13 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> 1) Modify resize_mini_window to use the minibuffer's font size to
> calculate the height when Vmax_mini_window_height is an int. (don't know
> if it is possible to access the minibuffer font size from there or if
> this could produce some undesired side effect)
> 
> 2) Modify the documentation of max-mini-window-height to specify that if
> an integer, it specifies a number of lines respecting to the frame's
> default font, not the minibuffer's visible lines.
> 
> 3) Just force the text to fit ignoring that the number of real visible
> lines will be different than max-mini-window-height. (This will be seen
> as ignoring the max-mini-window-height)
> 
> What do you think is better?

I agree with what Stefan says: our only practical choice is 2.
Minibuffer messages can legitimately use different fonts in each of
their lines, so using some different font will just move the problem
to other use cases.

In a nutshell, max-mini-window-height sets the limit in pixels, it
just expresses that limit in units of the canonical character height.