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