GNU bug report logs - #78418
31.0.50; Change in fit-frame-to-buffer doesn't work with transient-posframe

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: yhaoxie <at> gmail.com, 78418 <at> debbugs.gnu.org, tumashu <at> 163.com
Subject: bug#78418: 31.0.50; Change in fit-frame-to-buffer doesn't work with transient-posframe
Date: Thu, 15 May 2025 10:14:42 +0200

[Message part 1 (text/plain, inline)]

>> And that from the first case?
>
> That's
>
> posframe.el:
>    840 (defun posframe--fit-frame-to-buffer (posframe max-height min-height max-width min-width only)
>    841   "POSFRAME version of function `fit-frame-to-buffer'.
>    842 Arguments HEIGHT, MAX-HEIGHT, MIN-HEIGHT, WIDTH, MAX-WIDTH,
>    843 MIN-WIDTH and ONLY are similar function `fit-frame-to-buffer''s."
>    844   ;; This only has effect if the user set the latter var to `hide'.
>    845   (let ((x-gtk-resize-child-frames posframe-gtk-resize-child-frames))
>    846     ;; More info: Don't skip empty lines when fitting mini frame to buffer (Bug#44080)
>    847     ;; http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e0de9f3295b4c46cb7198ec0b9634809d7b7a36d
>    848     (if (functionp 'fit-frame-to-buffer-1)
>    849         (fit-frame-to-buffer-1
>    850          posframe max-height min-height max-width min-width only nil nil)
>    851       (fit-frame-to-buffer
>    852        posframe max-height min-height max-width min-width only))))

This doesn't explain the 199 vs 216 dichotomy yet.

> And after some digging, I found several bindings for
> frame-resize-pixel-wise, for example in posframe-show which is in the
> backtrace.
>
> posframe.el:
>    419                               (window-tab-line-height)
>    420                             0))
>    421          (mouse-position (cdr (mouse-pixel-position)))
>    422          (frame-resize-pixelwise t)
>    423          posframe)
>
> If I understand correctly what you write further down, this should not
> be done, right? (Feng Shu <tumashu <at> 163.com> added to CC, the posframe
> author).

It might work if the frame is short-lived enough.  The problem with it
is that subsequent operations on that frame will immediately undo the
pixelwise effect unless they again bind 'frame-resize-pixelwise'.

> Si I guess that explains that difference.

You would have to always report the value of 'frame-resize-pixelwise'
too when you report the values calculated by 'fit-frame-to-buffer'.

> If you express it that way, I almost understand what it does :-).

Users should always set 'frame-resize-pixelwise' to t unless they rely
on two effects provided by window managers:

- When you drag a frame border with the mouse a pixelwise frame grows or
  shrinks by one pixel.  A non-pixelwise frame can grow or shrink by a
  line and/or column only.

- With some WMs when you drag a frame border with the mouse you get some
  feedback about the current size of the frame in some sort of a window
  on top of it.  See the attached resize.png with the (84x36) text in
  the center of the frame - that's how xfwm displays that information
  here.

Non-pixelwise frames behave like terminal windows - they cannot be
maximized orderly and do not play well with tiling WMs.  And since we
never fixed size hints to work orderly with decorations, frames cannot
be fit well to the sizes of their buffers.

> So, if
> my WM is not ever rounding down, I should set it to t? Might be a good
> default for macOS...

I would set it regardless of whether my WM rounds down or not.

martin

[resize.png (image/png, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.