My expectation was that clone-frame, when frame-resize-pixelwise t, would implicitly DTRT. I expect most people would have the same expectation. Same as frameset-restore (now fixed with the patch).

When packages we use invoke clone-frame, we can't control their parameterization of those invocations without advice, so implied pixelwise seems wise. I added the explicit parameter more as awareness than anything else, but I imagine that carefully-crafted pixelwise child frames in packages may want explicit pixelwise clones if the authors aren't going to let-bind frame-resize-pixelwise around clone-frame calls. I'd prefer that we recommend that, actually.

Let's just do away with the pixelwise parameter and rely on the user setting? That would be in keeping with the rest of the implementation, I think.

On Mon, Dec 16, 2024 at 4:32 AM martin rudalics <rudalics@gmx.at> wrote:

> I'd write that as
>
> If PIXELWISE or `frame-resize-pixelwise' is non-nil and FRAME's terminal
> is not text-only, use the pixel size of FRAME for the cloned frame.
> Otherwise, use the number of columns and lines of FRAME for the cloned
> frame.

But may be we should write

(and pixelwise frame-resize-pixelwise))

and say

If PIXELWISE and `frame-resize-pixelwise' are both non-nil and FRAME's
terminal is not text-only, use the pixel size of FRAME for the cloned
frame. Otherwise, use the number of columns and lines of FRAME for
the cloned frame.

Setting PIXELWISE to t in a setting where 'frame-resize-pixelwise' is
nil means asking for trouble since the window manager might not honor
it. WDYT?

martin