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

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

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.