bug#74750: clone-frame and make-frame pixelwise issues

[Ship Mints <shipmints@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3444 bytes --]

With your suggested wording changes but without the pixelwise argument:

(defun clone-frame (&optional frame no-windows)
  "Make a new frame with the same parameters and windows as FRAME.
With a prefix arg NO-WINDOWS, don't clone the window configuration. When
the user option `frame-resize-pixelwise' is non-nil, and FRAME is not
text-only, clone the originating frame's pixel size. Otherwise, use the
number of FRAME's columns and lines in the clone.

FRAME defaults to the selected frame.  The frame is created on the
same terminal as FRAME.  If the terminal is a text-only terminal then
also select the new frame."
  (interactive (list (selected-frame) current-prefix-arg))
  (let* ((frame (or frame (selected-frame)))
         (windows (unless no-windows
                    (window-state-get (frame-root-window frame))))
         (default-frame-alist
          (seq-remove (lambda (elem)
                        (memq (car elem) frame-internal-parameters))
                      (frame-parameters frame)))
         (new-frame))
    (when (and (display-graphic-p frame)
               frame-resize-pixelwise)
      (push (cons 'width (cons 'text-pixels (frame-text-width frame)))
            default-frame-alist)
      (push (cons 'height (cons 'text-pixels (frame-text-height frame)))
            default-frame-alist))
    (setq new-frame (make-frame))
    (when windows
      (window-state-put windows (frame-root-window new-frame) 'safe))
    (unless (display-graphic-p frame)
      (select-frame new-frame))
    new-frame))

On Mon, Dec 16, 2024 at 5:40 AM Ship Mints <shipmints@gmail.com> wrote:

> 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
>>
>

[-- Attachment #2: Type: text/html, Size: 4816 bytes --]