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

["Óscar Fuentes" <ofv@wanadoo.es>]

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.