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
>