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.