bug#37563: 27.0.50; fit-frame-to-buffer does not account for line-spacing

[Ingo Lohmar <ingo.lohmar@posteo.net>]

On Mon, Oct 07 2019 11:25 (+0200), martin rudalics wrote:

> I now came up with a fix for 'fit-window-to-buffer' too which had some
> strange misbehavior with different size restricting arguments when the
> window's text size did not change.  See attached diffs and Change Log
> below.
>
>  > I think I understand better now, I was hampered by some weird debugging
>  > artifacts in my current setup.  With the default
>  > `frame-resize-pixelwise' of nil, and the otherwise bug-fixed code,
>  > nothing is cut off, but there is some slack whitespace, indeed.
>
> I suppose that part of that whitespace comes from the fact that with
> 'line-spacing' greater zero, 'window-text-pixel-size' includes the
> space below the last line of its text.  It would be nice to get rid of
> that but ISTR that a line's text may now get centered within the space
> reserved for it.  So I cannot just remove the entire line space of one
> line from the return value but probably only half of the line spacing
> value.  How would I know the right value?

I think we're talking about different things.  I was talking about the
(correct) rounding to a char-height multiple at the end of
`fit-frame-to-buffer'.  This is unaffected by the line-spacing.

Example (line-spacing 1, frame-resize-pixelwise nil):

I had 8 lines of char-height 14, leading to 8*(14+1) = 120 pixels (from
window-text-pixel-size, AFAICS) before the rounding.  Rounding to a
multiple of 14, but at least as large leads to height 126, and these 6
extra pixels are what I saw.

As an aside, the posframe pkg explicitly sets `frame-resize-pixelwise'
to t, presumable to avoid the rounding, which is the correct approach
for this package, I think.

In any case, I am happy that this will be fixed, and, coming from the
application side, have probably not much else to contribute :)

Ingo