bug#56102: 29.0.50; fit-frame-to-buffer's window-text-pixel-size calculation can be incorrect when only is set to vertically

[martin rudalics]

> That seems to work for me. I do wonder though if the the check for
> `only' should be first (i.e. if only is vertically, max-width is nil).
> Is there a reason that we should not ignore a specified max-width when
> only is set to vertically?

The idea of 'fit-frame-to-buffer' was that an application should be able
to call it (maybe implicitly via 'temp-buffer-resize-mode') and not care
about where on the display the frame will be shown.  Hence, a major
concern of its design was to constrain the frame to some specified area
on the display, to avoid that parts of it move off screen.  That's why
'fit-frame-to-buffer-margins' and 'fit-frame-to-buffer-sizes' have been
provided.

Currently, we check for an explicit MAX-WIDTH first and then consult
'fit-frame-to-buffer-sizes' via SIZES as

                    ((numberp max-width) (* max-width char-width))
                    ((numberp (nth 2 sizes)) (* (nth 2 sizes) char-width))

If we were to override MAX-WIDTH by setting ONLY to 'vertically', where
and how would we check SIZES?

> I ask because in the package that I had
> this issue with I employed a work-around where I set the max-width to
> (frame-parameter frame 'width), which seems to work well enough, but
> probably not as good as your fix. We may not be able to remove that
> workaround for some time, so ignoring max-width if set would probably
> work better in our specific case.

Are these issues really related?  If your workaround works, it should
continue working regardless of whether we ignore MAX-WIDTH when ONLY is
'vertically' or not.  Or am I missing something?

martin