Subject: Re: 31.0.50; Change in fit-frame-to-buffer doesn't work with transient-posframe

From: Gerd Möllmann <[email-masked]>
Date: Mon, 19 May 2025 16:04:36 +0200

martin rudalics <[email-masked]> writes:

>>> When on macOS with 'frame-resize-pixelwise' nil you drag a frame border
>>> with the mouse, does it resize by pixels or by character increments?
>>
>> I think it resizes to character bounds with frame-resize-pixelwise nil,
>> and to pixels with it being t.
>
> But did you try?  

Sure. With frame-resize-pixelwise t, I can drag the right side of the
frame so that I get this:

Note that I can make it end in the middle of the 'm' in the header-line.
With frame-resize-pixel-wise nil I can't get that. It "snaps" to character
boundaries like so

> I see PResizeInc defined in nsgui.h but I nowhere see it used. Same
> goes for Wayland builds. AFAICT size increments are only recognized by
> X11. Everywhere else they are a pure nuisance.

Don't know what that means, sorry. And I don't know what is causing
this different behavior.

>> For transient-posframe child frames, when f-r-p is nil. things go wrong
>> because Posframe binds frame-resize-pixelwise to t, and transient uses
>> the default nil when fit-frame-to-buffer is called. That's what I showed
>> in the screen shot.
>
> That's a different issue.  If 'frame-resize-pixelwise' is nil,
> 'fit-frame-to-buffer-1' does all that silly rounding which blows frames
> up in your case.

It's the only reason I ask if we should change the default value. Or
Posframe shouldn't bind frame-resize-pixelwise, or Transient should not
call fit-buffer-to-frame, or whatever. As it stands, it will lead to bug
reports. Not that it matters much, of course.