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 <rudalics@gmx.at>]

 > 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