From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ship Mints Newsgroups: gmane.emacs.bugs Subject: bug#74750: clone-frame and make-frame pixelwise issues Date: Mon, 16 Dec 2024 05:48:24 -0500 Message-ID: References: <861pyfd8pe.fsf@gnu.org> <4d057282-8ec2-4ddb-ac0f-23e65af6e5a1@gmx.at> <7404039b-e71e-44e5-a446-70fa07889528@gmx.at> <1ed054fc-4b82-47cf-8d89-4768b56b88a7@gmx.at> <544d13ee-54f0-4786-8c5b-b1c87570f36c@gmx.at> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000475488062960eeab" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8120"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 74750@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 16 11:51:17 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tN8h2-0001rc-Kp for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Dec 2024 11:51:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tN8gr-0004Fl-JZ; Mon, 16 Dec 2024 05:51:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tN8gp-0004FV-UG for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 05:51:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tN8gp-0005Oj-2v for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 05:51:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=w1CeXvqO1QJ8jmTrVA5drzGtHlVShJp5oVix9VIkFaU=; b=DnLY4bRDCtsMo7Ooh1dmc3odVpw5B7nL4ojWPk8iM+xAy4NmQhaTXQ2W2t767L7B0FYNsHjcU4W71c9PRXBtQg7t8Ir8tDRAOmBulb2g7wtFuxeBtGP1OW+yvUr92/HTAZBto5mE3uX2j1RXbVL832y6+k0OOLpSEFaH2P0q384CF26IgN2vH9zGJ/YD7zDrFmXEe+NvNCOrdWmDN5x/tD1nYYdHrZEWzXCF8m6BkMvoGepPy5j1ZbZRjdj/a0+9PEIFffP8mOzo9Ze2KDM29OzruWmzZT2W8AcuIYm+JYp9SvWv7O5/lusvqZm22QUC4ExV472w7FNSA8QxhlfwZw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tN8go-0001Ya-Lj for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 05:51:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ship Mints Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Dec 2024 10:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74750 X-GNU-PR-Package: emacs Original-Received: via spool by 74750-submit@debbugs.gnu.org id=B74750.17343462155896 (code B ref 74750); Mon, 16 Dec 2024 10:51:02 +0000 Original-Received: (at 74750) by debbugs.gnu.org; 16 Dec 2024 10:50:15 +0000 Original-Received: from localhost ([127.0.0.1]:53741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tN8g2-0001X1-Pc for submit@debbugs.gnu.org; Mon, 16 Dec 2024 05:50:15 -0500 Original-Received: from mail-vs1-f51.google.com ([209.85.217.51]:50557) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tN8g0-0001Wq-1i for 74750@debbugs.gnu.org; Mon, 16 Dec 2024 05:50:12 -0500 Original-Received: by mail-vs1-f51.google.com with SMTP id ada2fe7eead31-4aff31b77e8so1175126137.1 for <74750@debbugs.gnu.org>; Mon, 16 Dec 2024 02:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734346151; x=1734950951; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=w1CeXvqO1QJ8jmTrVA5drzGtHlVShJp5oVix9VIkFaU=; b=Wis3Bokyrj32e+noCSbxrXMkqo2s36XGOEWSS9SpqP/cLH0ngd91cEm2FRoQASXHZl FyOlFuYAp79Bf9p6mRRgfkuyZsWNx3QlvnjSvTBv/+Nvg8ctzCiHOMDOzXB0cumPrGTd AxTIMn4rbIvgh9A4IULTIHC/HZvX2cLvXrLMgkDBsFvwY4q8QReCf6tJWWYfwcb2NAUc HI2FafSCogN0hIGsnH7s8OrHKMBnl2oL2ETx5pvhkLlm5LOqQgfhZEPGTChr1YOIyefh 8wjcAksqaXGg3omLMikKhN2ork+XqIn4PDm8jeQsKLr3aIccRFU7hJCnUIP7ZUCUoiWV u67w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734346151; x=1734950951; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=w1CeXvqO1QJ8jmTrVA5drzGtHlVShJp5oVix9VIkFaU=; b=Dk6SPQ86rLa+xfpDF9WRHTCeq78Vmge3avZ5hMH4U8DHmqGZ3rJUa/RjKUr/jD11LI /vwl7XYRsFZRE1DhMRZu/9t6nZI0HMZ9WPZD3nJOp6Dxc1sWuE/DFhg+aKjY3bFuw84K fi0Z5zyxUmD+MHWRx8dYjTyt0sreh7HCfEKtbtoFQmGhkl40wuOhzyX8pwdbE3uypEJ+ OG9RzLgIxJZ5LBOr5FBxuJzWdQPioKgyHCANZhd82D6K1YD25yJl0/jwDdEqoiwemCuY Yr06Xutmi4YmnpQAvyBmCXQYwtk9+UxvdsrXKR5hDiSD0uqZRCrbnBwrqmHnVCICxRNO baHA== X-Forwarded-Encrypted: i=1; AJvYcCWLWSBPwy/QsiGlXPFRVRWK9ESDFYoi2/6OzWfsK55grYcredXojQFLxiFCFieKLCAzn2ytKQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxlzjIm2BcHtD3R50nNcdDMJDc6YD0htqeBNq9SkBk6XJ6epIue +r+X8N44cfvOKFPzo7jQW38yGPRL4jBe7xOOqGxrbsocUeHoLwXtKGd6fZVSMN5XhHF8nfvtWiI wNfWkkQmzUBhNyK4FgJjNlMplgp0= X-Gm-Gg: ASbGncuJHiv7zPmtqfK7CyLKA0x1X5YnK9yM+QzjLM0oyAK99WeJmyeqP9gmcg4kRaD oWaAQSQFqrCn3AaJ9hFUl5hu+vjWiVd6GIhX1Eg== X-Google-Smtp-Source: AGHT+IHq6gnHoin5tUWqsPojRglscdYY7PyrvVqMK5GEbHfVLdvu6KU7MIApYPC9/99BedoymqUlCQrM+PXMYHEYoPc= X-Received: by 2002:a05:6102:4414:b0:4b1:101f:a5a0 with SMTP id ada2fe7eead31-4b25dc631acmr10410189137.5.1734346151512; Mon, 16 Dec 2024 02:49:11 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:297163 Archived-At: --000000000000475488062960eeab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Ship Mints wr= ote: > My expectation was that clone-frame, when frame-resize-pixelwise t, would > implicitly DTRT. I expect most people would have the same expectation. Sa= me > 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=E2=80=AFAM martin rudalics = 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 >> > --000000000000475488062960eeab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With your suggested wording changes but without the pixelwise argument:<= /div>

(defun clone-= frame (&optional frame no-windows)
=C2=A0 "Make a new frame wit= h 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&#= 39;s columns and lines in the clone.

FRAME defaults to the selected = frame.=C2=A0 The frame is created on the
same terminal as FRAME.=C2=A0 I= f the terminal is a text-only terminal then
also select the new frame.&q= uot;
=C2=A0 (interactive (list (selected-frame) current-prefix-arg))
= =C2=A0 (let* ((frame (or frame (selected-frame)))
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0(windows (unless no-windows
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (window-state-get (frame-root-window= frame))))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(default-frame-alist
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (seq-remove (lambda (elem)
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (mem= q (car elem) frame-internal-parameters))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (frame-parameters frame)))=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(new-frame))
=C2=A0 =C2=A0 (when (and= (display-graphic-p frame)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0frame-resize-pixelwise)
=C2=A0 =C2=A0 =C2=A0 (push (cons '= width (cons 'text-pixels (frame-text-width frame)))
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 default-frame-alist)
=C2=A0 =C2=A0 =C2=A0 (p= ush (cons 'height (cons 'text-pixels (frame-text-height frame)))=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 default-frame-alist))
=C2=A0 = =C2=A0 (setq new-frame (make-frame))
=C2=A0 =C2=A0 (when windows
=C2= =A0 =C2=A0 =C2=A0 (window-state-put windows (frame-root-window new-frame) &= #39;safe))
=C2=A0 =C2=A0 (unless (display-graphic-p frame)
=C2=A0 =C2= =A0 =C2=A0 (select-frame new-frame))
=C2=A0 =C2=A0 new-frame))
=

On Mon, Dec 16, 2024 at 5:40=E2=80=AFAM Ship Mints &l= t;shipmints@gmail.com> wrote:=
My expectati= on=C2=A0was that clone-frame, when frame-resize-pixelwise t, would implicit= ly DTRT. I expect most people would have the same expectation. Same as fram= eset-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=C2=A0pixelwise=C2=A0seems wise. I added the explicit parameter m= ore as awareness than anything else, but I imagine that carefully-crafted p= ixelwise=C2=A0child frames in packages may want explicit pixelwise clones i= f the authors aren't going to let-bind frame-resize-pixelwise around cl= one-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 i= n keeping with the rest of the implementation, I think.

On Mon, Dec 16= , 2024 at 4:32=E2=80=AFAM martin rudalics <rudalics@gmx.at> wrote:
=C2=A0> I'd write that as
=C2=A0>
=C2=A0>=C2=A0 =C2=A0 If PIXELWISE or `frame-resize-pixelwise' is non= -nil and FRAME's terminal
=C2=A0>=C2=A0 =C2=A0 is not text-only, use the pixel size of FRAME for t= he cloned frame.
=C2=A0>=C2=A0 =C2=A0 Otherwise, use the number of columns and lines of F= RAME for the cloned
=C2=A0>=C2=A0 =C2=A0 frame.

But may be we should write

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (and pixelwise fram= e-resize-pixelwise))

and say

=C2=A0 =C2=A0If PIXELWISE and `frame-resize-pixelwise' are both non-nil= and FRAME's
=C2=A0 =C2=A0terminal is not text-only, use the pixel size of FRAME for the= cloned
=C2=A0 =C2=A0frame.=C2=A0 Otherwise, use the number of columns and lines of= FRAME for
=C2=A0 =C2=A0the 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.=C2=A0 WDYT?

martin
--000000000000475488062960eeab--