bug#50178: 28.0.50; Size of echo area does not account for line-spacing

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Óscar Fuentes]

Seems that on some circunstances the vertical space calculated for the
text on the echo area does not account for the value of line-spacing:

emacs -Q
M-x icomplete-vertical-mode
M-x fido-mode
(set-default 'line-spacing 0.1)

Now M-x will display a list of candidates with the last candidate
partially visible for lack of vertical space.


In GNU Emacs 28.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0)
 of 2021-07-30 built on sky
Repository revision: d9bc7dbefd88995d04b9843f521d82118265fecf
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --with-native-compilation --without-toolkit-scroll-bars
 --with-x-toolkit=lucid --with-modules --without-imagemagick
 build_alias= host_alias= target_alias='

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND THREADS TIFF X11 XAW3D XDBE XIM XPM LUCID ZLIB

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 24 Aug 2021 04:08:41 +0200
> 
> Seems that on some circunstances the vertical space calculated for the
> text on the echo area does not account for the value of line-spacing:
> 
> emacs -Q
> M-x icomplete-vertical-mode
> M-x fido-mode
> (set-default 'line-spacing 0.1)
> 
> Now M-x will display a list of candidates with the last candidate
> partially visible for lack of vertical space.

And why is that a problem?  Emacs displays partially visible lines at
end of window in many cases; as long as the list of completion
candidates is long enough, you cannot see all of them anyway.

Or maybe you have a specific recipe in mind where this works
incorrectly, in which case please show that recipe.

Thanks.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> And why is that a problem?  Emacs displays partially visible lines at
> end of window in many cases; as long as the list of completion
> candidates is long enough, you cannot see all of them anyway.
>
> Or maybe you have a specific recipe in mind where this works
> incorrectly, in which case please show that recipe.

There are some packages that works displaying a certain number of lines
on the echo area (ido-grid-mode, for instance.) They set
max-mini-window-height to an integer and expect that Emacs will take
care of resizing the echo area accordingly, if possible. If the
resulting echo area is not tall enough, there is a problem.

IMO max-mini-window-height, when set to an integer, should mean "I want
this many lines", as it does when line-spacing is nil. Otherwise every
one of those packages must implement the heuristics for taking into
account `line-spacing' and any other present and future variable that
might affect the number of lines visible on the echo area.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 50178@debbugs.gnu.org
> Date: Tue, 24 Aug 2021 15:34:27 +0200
> 
> There are some packages that works displaying a certain number of lines
> on the echo area (ido-grid-mode, for instance.) They set
> max-mini-window-height to an integer and expect that Emacs will take
> care of resizing the echo area accordingly, if possible. If the
> resulting echo area is not tall enough, there is a problem.
> 
> IMO max-mini-window-height, when set to an integer, should mean "I want
> this many lines", as it does when line-spacing is nil.

But that's not the exact meaning of the value of that variable.  The
doc string says:

  If an integer, it specifies the maximum height in units of the
  mini-window frame’s default font’s height.     ^^^^^^^^^^^^^^^
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It is measured in units of the canonical character height, and that
doesn't take the line-spacing into account, like it doesn't take into
account faces that change the font or the size of the characters.

IOW, the value means "this many lines", but assuming that the line's
height is the one you get with the frame's default font.

You get the same in a window other than mini-window: if you set
line-spacing, chances are the last screen line will be only partially
visible.  Why should the mini-window be different? it's just another
window.

So once again, I see no problem here, it's just Emacs display working
as designed in the face of variable-size fonts and window heights that
aren't necessarily an integral multiple of the font/line height.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> IMO max-mini-window-height, when set to an integer, should mean "I want
>> this many lines", as it does when line-spacing is nil.
>
> But that's not the exact meaning of the value of that variable.  The
> doc string says:
>
>   If an integer, it specifies the maximum height in units of the
>   mini-window frame’s default font’s height.     ^^^^^^^^^^^^^^^
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> It is measured in units of the canonical character height, and that
> doesn't take the line-spacing into account, like it doesn't take into
> account faces that change the font or the size of the characters.
>
> IOW, the value means "this many lines", but assuming that the line's
> height is the one you get with the frame's default font.

IMAO the case where the user wants to ensure that the mini window is
capable of displaying at least X lines is much more common than the user
wanting a height of at least X times the default font's height.
Crucially, the first case is about showing information, while the second
is about aesthetics (suppossing that it is used at all with that
intention.)

I suspect that max-mini-window-height was introduced with the former use
case in mind, but was not updated when line-spacing was implemented
later.

If we have no method for ensuring that the echo area is capable of
displaying at least X lines (within some reasonable limits) then we need
one.

> You get the same in a window other than mini-window: if you set
> line-spacing, chances are the last screen line will be only partially
> visible.  Why should the mini-window be different? it's just another
> window.

You can't navigate around on the contents of the mini-window. If a
package can't rely on setting max-mini-window-height for showing certain
number of lines on the mini-window, then it must implement vertical
scrolling, which makes things complex both on the programming side and
on the UI side, just to make sure that the user can access the content's
of the overflowing line(s), if any.

The case of ido-grid-mode is glaring: it has a defcustom for setting how
many lines to show. When the command is invoked, it sets
max-mini-window-height accordingly (what else could it do?) but if
line-spacing is not nil, the bottom line(s) might not be visible.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 50178@debbugs.gnu.org
> Date: Tue, 24 Aug 2021 19:44:37 +0200
> X-Spam-Status: No
> 
> > IOW, the value means "this many lines", but assuming that the line's
> > height is the one you get with the frame's default font.
> 
> IMAO the case where the user wants to ensure that the mini window is
> capable of displaying at least X lines is much more common than the user
> wanting a height of at least X times the default font's height.

But the former is basically impossible to provide, not in Emacs 21+
with its support for variable-size fonts and display of images and
xwidgets as part of text.  Even with just different fonts, N lines
using font of size X are not the same as N lines with size Y.

> I suspect that max-mini-window-height was introduced with the former use
> case in mind, but was not updated when line-spacing was implemented
> later.

No, max-mini-window-height is consistent with how we size all the
windows in Emacs: in units of the canonical character height and
width.  That's our usual paradigm.

> If we have no method for ensuring that the echo area is capable of
> displaying at least X lines (within some reasonable limits) then we need
> one.

It would mean a different height for each piece of text you display.
It will cause the mode line to jump up and down like a wild goat, even
if a message applies some innocent non-default faces.

It's not how Emacs is designed to work.  It basically works in pixels,
not in lines, and just converts from and to canonical character units
to make it easier for users to specify values.

> > You get the same in a window other than mini-window: if you set
> > line-spacing, chances are the last screen line will be only partially
> > visible.  Why should the mini-window be different? it's just another
> > window.
> 
> You can't navigate around on the contents of the mini-window.

??? Of course, I can.  What do you mean by "you can't"?  The
mini-window is just another window, so as long as you can make it the
selected window (e.g., when the minibuffer is active), you can
navigate there.

> If a
> package can't rely on setting max-mini-window-height for showing certain
> number of lines on the mini-window, then it must implement vertical
> scrolling, which makes things complex both on the programming side and
> on the UI side, just to make sure that the user can access the content's
> of the overflowing line(s), if any.

The recipe you show in the bug report does support scrolling: the up-
and down-arrow keys scroll the list of candidates.

> The case of ido-grid-mode is glaring: it has a defcustom for setting how
> many lines to show. When the command is invoked, it sets
> max-mini-window-height accordingly (what else could it do?) but if
> line-spacing is not nil, the bottom line(s) might not be visible.

There was no ido-grid-mode in the original report, so I guess you are
now talking about a different recipe?  Can you present it?  We could
then discuss those problems and what can be done about that.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> IMAO the case where the user wants to ensure that the mini window is
>> capable of displaying at least X lines is much more common than the user
>> wanting a height of at least X times the default font's height.
>
> But the former is basically impossible to provide, not in Emacs 21+
> with its support for variable-size fonts and display of images and
> xwidgets as part of text.  Even with just different fonts, N lines
> using font of size X are not the same as N lines with size Y.

We are talking about the mini window here. It's contents are much more
restricted, in the sense that it is determined by some command. This bug
report is about such command wanting to show at least N lines, using the
current display settings (font, line spacing, etc).

>> You can't navigate around on the contents of the mini-window.
>
> ??? Of course, I can.  What do you mean by "you can't"?  The
> mini-window is just another window, so as long as you can make it the
> selected window (e.g., when the minibuffer is active), you can
> navigate there.

Allowing the user to move around on the mini window possibly is at odds
with the UI of the command using the mini window. Certainly, it would be
an inconvenience, as I mentioned before.

>> If a
>> package can't rely on setting max-mini-window-height for showing certain
>> number of lines on the mini-window, then it must implement vertical
>> scrolling, which makes things complex both on the programming side and
>> on the UI side, just to make sure that the user can access the content's
>> of the overflowing line(s), if any.
>
> The recipe you show in the bug report does support scrolling: the up-
> and down-arrow keys scroll the list of candidates.

Yes, that was just an example for demonstrating the problem using stock
Emacs.

Curiously, something like

(message "foo1\nfoo2\nfoo3\nfoo4\nfoo4\nfoo5\nfoo6\nfoo7\nfoo8")

doesn't show truncated lines because it apparently ignores the value of
line-spacing.

> There was no ido-grid-mode in the original report, so I guess you are
> now talking about a different recipe?  Can you present it?  We could
> then discuss those problems and what can be done about that.

ido-grid-mode does not support vertical scrolling (it is not supposed to
do that and it would be a burden if it did) and with certain values of
line-spacing the last line(s) are partially visible or invisible. It's
as simple as that. It uses max-mini-window-height for ensuring that the
text fits on the mini-window, but that doesn't work on the presence of
line-spacing.

One workround would be to locally set line-spacing to nil (overriding
the user's preferences), but this does not protect against other current
or future settings that might affect how the lines are rendered.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 50178@debbugs.gnu.org
> Date: Tue, 24 Aug 2021 20:38:56 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But the former is basically impossible to provide, not in Emacs 21+
> > with its support for variable-size fonts and display of images and
> > xwidgets as part of text.  Even with just different fonts, N lines
> > using font of size X are not the same as N lines with size Y.
> 
> We are talking about the mini window here. It's contents are much more
> restricted, in the sense that it is determined by some command.

I don't really see how can we say that, given the proliferation of the
various completion packages, which display everything that can be
displayed in the mini-window.

> This bug report is about such command wanting to show at least N
> lines, using the current display settings (font, line spacing, etc).

And I still don't understand what is wrong with the recipe you've
shown.  In my testing, I see a very long list of candidates, with
several ones fully visible and one visible only partially.  I can
scroll down the list to see more candidates, including the one which
was initially displayed partially.  I fail to see a problem with that,
sorry.

> >> You can't navigate around on the contents of the mini-window.
> >
> > ??? Of course, I can.  What do you mean by "you can't"?  The
> > mini-window is just another window, so as long as you can make it the
> > selected window (e.g., when the minibuffer is active), you can
> > navigate there.
> 
> Allowing the user to move around on the mini window possibly is at odds
> with the UI of the command using the mini window. Certainly, it would be
> an inconvenience, as I mentioned before.

Again, I don't see any inconvenience.  It's just the normal vertical
motion of the cursor, not unlike any other window.

> Curiously, something like
> 
> (message "foo1\nfoo2\nfoo3\nfoo4\nfoo4\nfoo5\nfoo6\nfoo7\nfoo8")
> 
> doesn't show truncated lines because it apparently ignores the value of
> line-spacing.

It does here, I guess you didn't turn line-spacing by default or
something.  Try

  emacs -Q --eval "(setq-default line-spacing 0.2)"

> ido-grid-mode does not support vertical scrolling (it is not supposed to
> do that and it would be a burden if it did) and with certain values of
> line-spacing the last line(s) are partially visible or invisible. It's
> as simple as that. It uses max-mini-window-height for ensuring that the
> text fits on the mini-window, but that doesn't work on the presence of
> line-spacing.
> 
> One workround would be to locally set line-spacing to nil (overriding
> the user's preferences), but this does not protect against other current
> or future settings that might affect how the lines are rendered.

Or it could calculate max-mini-window-height more accurately.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> One workround would be to locally set line-spacing to nil (overriding
>> the user's preferences), but this does not protect against other current
>> or future settings that might affect how the lines are rendered.
>
> Or it could calculate max-mini-window-height more accurately.

It must know and handle every setting that affects line height, current
and future. It would be handy if Emacs provided a function that does
that.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 50178@debbugs.gnu.org
> Date: Tue, 24 Aug 2021 21:36:58 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Or it could calculate max-mini-window-height more accurately.
> 
> It must know and handle every setting that affects line height, current
> and future. It would be handy if Emacs provided a function that does
> that.

We already have it: window-text-pixel-size.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[martin rudalics]

 >> It must know and handle every setting that affects line height, current
 >> and future. It would be handy if Emacs provided a function that does
 >> that.
 >
 > We already have it: window-text-pixel-size.

To elaborate:

(1) You first have to calculate the maximum permissible pixel height of
     the echo area window from the character height of the frame where
     you intend to display the completions and the value of
     `max-mini-window-height' height as specified for that frame.  Note
     that for a minibuffer-less frame the echo area window may appear on
     another frame whose character height you have to use here.

(2) You then have to calculate the pixel height of each completion line
     as if it were shown in the echo area window mentioned in (1) using
     `window-text-pixel-size' and add it to some cumulative height until
     you have exhausted the maximum permissible height calculated in (1).

martin

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Gregory Heytings]

>
> To elaborate:
>
> (1) You first have to calculate the maximum permissible pixel height of 
> the echo area window from the character height of the frame where you 
> intend to display the completions and the value of 
> `max-mini-window-height' height as specified for that frame.  Note that 
> for a minibuffer-less frame the echo area window may appear on another 
> frame whose character height you have to use here.
>
> (2) You then have to calculate the pixel height of each completion line 
> as if it were shown in the echo area window mentioned in (1) using 
> `window-text-pixel-size' and add it to some cumulative height until you 
> have exhausted the maximum permissible height calculated in (1).
>

If you can live with the fact that the last visible completion candidate 
is not fully displayed (which is, as Eli said, consistent with what 
happens in other Emacs windows), this complex procedure is not necessary 
anymore.  You can simply set redisplay-adhoc-scroll-in-resize-mini-windows 
to nil and insert "enough" completion candidates.  Emacs will resize the 
window appropriately, and the last completion candidates will not be 
visible.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Óscar Fuentes]

martin rudalics <rudalics@gmx.at> writes:

>>> It must know and handle every setting that affects line height, current
>>> and future. It would be handy if Emacs provided a function that does
>>> that.
>>
>> We already have it: window-text-pixel-size.
>
> To elaborate:
>
> (1) You first have to calculate the maximum permissible pixel height of
>     the echo area window from the character height of the frame where
>     you intend to display the completions and the value of
>     `max-mini-window-height' height as specified for that frame.  Note
>     that for a minibuffer-less frame the echo area window may appear on
>     another frame whose character height you have to use here.
>
> (2) You then have to calculate the pixel height of each completion line
>     as if it were shown in the echo area window mentioned in (1) using
>     `window-text-pixel-size' and add it to some cumulative height until
>     you have exhausted the maximum permissible height calculated in (1).

Thanks. That's too complicated and looks like there are quite a bit of
hidden traps, so for the time being I'll set line-spacing to nil.

On true pixel-oriented systems there are APIs for querying the display
engine about several metrics. Then you can place the text at certain
pixel coordinates. Emacs, however, is a Frankenstein system, that uses
pixels (on graphic frames) but the text positioning depends on previous
text, i.e. for vertical positioning it is a line-based, not pixel-based,
system. Therefore, when you just need to output some lines, you must
deal with pixels, translate back to lines and, to add insult to injury,
resort to post-facto information.

As useful as it would be an API that returns how many lines fit on a
given window. Or, on this case, max-mini-window-height being a true
indication of the capacity of the mini window on terms of the current
display settings, which is what the users want 99.9% of the time.

Closing.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: Eli Zaretskii <eliz@gnu.org>,  50178-done@debbugs.gnu.org
> Date: Wed, 25 Aug 2021 12:49:39 +0200
> 
> As useful as it would be an API that returns how many lines fit on a
> given window.

What is a "line" for this purpose?  The notion of a "canonical line"
is well defined, and that is what we use.  Any other notion will have
to be defined first, and it isn't easy, I can tell you.

> Or, on this case, max-mini-window-height being a true
> indication of the capacity of the mini window on terms of the current
> display settings, which is what the users want 99.9% of the time.

Unless you counted only yourself in those 99.9%, it is a strange thing
to say about the modern Emacs.  It's as if you wanted to go back to
Emacs 18, where all lines were the same height.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Gregory Heytings]

>
> On true pixel-oriented systems there are APIs for querying the display 
> engine about several metrics. Then you can place the text at certain 
> pixel coordinates. Emacs, however, is a Frankenstein system, that uses 
> pixels (on graphic frames) but the text positioning depends on previous 
> text, i.e. for vertical positioning it is a line-based, not pixel-based, 
> system. Therefore, when you just need to output some lines, you must 
> deal with pixels, translate back to lines and, to add insult to injury, 
> resort to post-facto information.
>
> As useful as it would be an API that returns how many lines fit on a 
> given window. Or, on this case, max-mini-window-height being a true 
> indication of the capacity of the mini window on terms of the current 
> display settings, which is what the users want 99.9% of the time.
>

Try emacs -Q, C-h h to see why it is impossible to have "an API that 
returns how many lines fit on a given window".

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Óscar Fuentes]

Gregory Heytings <gregory@heytings.org> writes:

> Try emacs -Q, C-h h to see why it is impossible to have "an API that
> returns how many lines fit on a given window".

Any graphics environment worth its salt has methods for measuring
whatever object without actually rendering it. It's also true that those
systems work on pixels (or some other suitable, fine-grained unit) all
the way, they do not reveal themselves as TTY-oriented systems when the
user says "ok, then put this right here." The impossibility you mention
is a limitation of Emacs.

So going back to Emacs, the doctstring of max-mini-window-height is

"...
If an integer, it specifies the maximum height in units of the
mini-window frame’s default font’s height.
"

Why that was implemented that way? (instead of using pixels, for
instance.) Maybe because the relevant use case was to support resizing
the mini window on a way that guarantees that certain number of lines
(rendered on the default font) will fit on it?

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 25 Aug 2021 19:09:14 +0200
> Cc: 50178-done@debbugs.gnu.org
> 
> Gregory Heytings <gregory@heytings.org> writes:
> 
> > Try emacs -Q, C-h h to see why it is impossible to have "an API that
> > returns how many lines fit on a given window".
> 
> Any graphics environment worth its salt has methods for measuring
> whatever object without actually rendering it.

So does Emacs: that's what window-text-pixel-size does.

> If an integer, it specifies the maximum height in units of the
> mini-window frame’s default font’s height.
> "
> 
> Why that was implemented that way? (instead of using pixels, for
> instance.)

Because in most cases it's more useful: it approximates the actual
number of lines quite well.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Any graphics environment worth its salt has methods for measuring
>> whatever object without actually rendering it.
>
> So does Emacs: that's what window-text-pixel-size does.

You missed the part "without actually rendering it".

As per Martin's instructions, the method for ensuring that the text does
not overflow the window is to put text on it, one line at a time, and
watch the used space (I guess that two lines would be enough to
extrapolate the space required by N lines assuming that the text is
rendered with the default font, face, etc)

On the case of ido-grid-mode (which displays a grid N lines tall that
virtually expands horizontally) not knowing in advance how many lines
are available means that it must populate the mini window with some
dummy text to measure its capacity, throw away its contents and proceed
to fill the mini window with the real payload.

>> If an integer, it specifies the maximum height in units of the
>> mini-window frame’s default font’s height.
>> "
>> 
>> Why that was implemented that way? (instead of using pixels, for
>> instance.)
>
> Because in most cases it's more useful: it approximates the actual
> number of lines quite well.

Exactly, that was my point all along. And it would be a better
approximation if the display engine used that variable taking into
account line-spacing and other relevant settings which affect how the
actual text is rendered.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: gregory@heytings.org,  50178@debbugs.gnu.org
> Date: Wed, 25 Aug 2021 22:10:03 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Any graphics environment worth its salt has methods for measuring
> >> whatever object without actually rendering it.
> >
> > So does Emacs: that's what window-text-pixel-size does.
> 
> You missed the part "without actually rendering it".

No, I didn't.  window-text-pixel-size doesn't render the text, it
_simulates_ its rendering internally.  You can look at its source if
you don't believe me.

> As per Martin's instructions, the method for ensuring that the text does
> not overflow the window is to put text on it, one line at a time, and
> watch the used space (I guess that two lines would be enough to
> extrapolate the space required by N lines assuming that the text is
> rendered with the default font, face, etc)

Martin's instructions notwithstanding, I stand by what I wrote.  Yes,
you need a window to compute the metrics, but that's only because some
of the factors that determine the metrics can vary between windows.
The window you pass to window-text-pixel-size doesn't need to be the
same window where you will eventually display the text, it just should
have the same window-specific parameters as the eventual one.

> On the case of ido-grid-mode (which displays a grid N lines tall that
> virtually expands horizontally) not knowing in advance how many lines
> are available means that it must populate the mini window with some
> dummy text to measure its capacity, throw away its contents and proceed
> to fill the mini window with the real payload.

Your conclusions are incorrect.

Are you familiar with fit-window-to-buffer?  Do you know that Help
commands use that every time to dynamically decide how to size the
window showing help?  If so, doesn't the fact that this mechanism
exists and works contradict your conclusions from what was said here?

> >> Why that was implemented that way? (instead of using pixels, for
> >> instance.)
> >
> > Because in most cases it's more useful: it approximates the actual
> > number of lines quite well.
> 
> Exactly, that was my point all along. And it would be a better
> approximation if the display engine used that variable taking into
> account line-spacing and other relevant settings which affect how the
> actual text is rendered.

I said "in most cases".  It is impossible to do that in all cases.
The case you are talking about is one of the rare exceptions.

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[martin rudalics]

 > On true pixel-oriented systems there are APIs for querying the display
 > engine about several metrics. Then you can place the text at certain
 > pixel coordinates. Emacs, however, is a Frankenstein system, that uses
 > pixels (on graphic frames) but the text positioning depends on previous
 > text, i.e. for vertical positioning it is a line-based, not pixel-based,
 > system. Therefore, when you just need to output some lines, you must
 > deal with pixels, translate back to lines and, to add insult to injury,
 > resort to post-facto information.

Users think in terms of lines and columns.  True pixel-oriented systems
are not convenient for editing.  A few days ago I spent a couple of
hours to remove one single line from a pdf-document using LibreOffice.
I almost succeeded.

 > As useful as it would be an API that returns how many lines fit on a
 > given window. Or, on this case, max-mini-window-height being a true
 > indication of the capacity of the mini window on terms of the current
 > display settings, which is what the users want 99.9% of the time.

Did you try with `redisplay-adhoc-scroll-in-resize-mini-windows' as
Gregory proposed?

martin

bug#50178: 28.0.50; Size of echo area does not account for line-spacing

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, 50178-done@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 26 Aug 2021 09:54:51 +0200
> 
>  > On true pixel-oriented systems there are APIs for querying the display
>  > engine about several metrics. Then you can place the text at certain
>  > pixel coordinates. Emacs, however, is a Frankenstein system, that uses
>  > pixels (on graphic frames) but the text positioning depends on previous
>  > text, i.e. for vertical positioning it is a line-based, not pixel-based,
>  > system. Therefore, when you just need to output some lines, you must
>  > deal with pixels, translate back to lines and, to add insult to injury,
>  > resort to post-facto information.
> 
> Users think in terms of lines and columns.  True pixel-oriented systems
> are not convenient for editing.

Yes.  Most users won't know the pixel height and width of what we call
"the canonical character" in Emacs.  I only know that because I hack
the display code (which works almost entirely in pixels) frequently
enough to have those values burned into my memory, and even that only
on my main development system.  So the average users out there would
be unable to specify dimensions in pixels, as the dimensions they have
in mind are in lines and columns.