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

[Eli Zaretskii <eliz@gnu.org>]

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