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:40:22 -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="000000000000898fd8062960d1af" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19044"; 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:43:27 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 1tN8ZR-0004kG-IA for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Dec 2024 11:43:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tN8Z6-00033q-Ok; Mon, 16 Dec 2024 05:43:04 -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 1tN8Z4-00033d-LN for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 05:43:02 -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 1tN8Z4-0004gu-Cu for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 05:43:02 -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=IboBFHnFjMRmj4U7b2A87R42I5K57Ju3A5WfXm90ceY=; b=puvy4MFOaoBm5iNUk6mKkw+8KPOYnmQOXAzNpeJb+1jhSjgV6mKLG2lKXRuEqPiiR1cR2mZ8Y2WOam0hCOm1UYZRmaOClbDAuWGZpcRZDyDLABRrW1qMHSA7stVdVlhGUzLLPoad7leS9xl+AMApKkvSGCZMLR8wqkv0dOFnssch7vOdZYZOCrnVA+tg2nhR85Grm1QLcnMV/q5lUzxHNRgNaDOi55K1iyHd/zBBiaEnxwrW2UHVXnEA6VOOGI2mJVOfU5t10lp6S9WCFdU5WDN4Ox0ChLS0mXSdXNoeSBSLVnl91IeHQyQjnnG6GRku0j2u4h46Uuvf4nKA1gpysA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tN8Z3-00017I-Uu for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 05:43: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:43:01 +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.17343457374193 (code B ref 74750); Mon, 16 Dec 2024 10:43:01 +0000 Original-Received: (at 74750) by debbugs.gnu.org; 16 Dec 2024 10:42:17 +0000 Original-Received: from localhost ([127.0.0.1]:53728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tN8YK-00015Z-Kc for submit@debbugs.gnu.org; Mon, 16 Dec 2024 05:42:17 -0500 Original-Received: from mail-vk1-f172.google.com ([209.85.221.172]:58701) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tN8YI-00015G-SS for 74750@debbugs.gnu.org; Mon, 16 Dec 2024 05:42:15 -0500 Original-Received: by mail-vk1-f172.google.com with SMTP id 71dfb90a1353d-5174f9c0e63so1042362e0c.1 for <74750@debbugs.gnu.org>; Mon, 16 Dec 2024 02:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734345669; x=1734950469; 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=IboBFHnFjMRmj4U7b2A87R42I5K57Ju3A5WfXm90ceY=; b=V1l4197HrY7TiE5OxCtkQ0X8UwwWehsyN0yWeaZOFjBRMi15o85lSd7MM+oGDndohy mbvC/kfSyDXwlR+ibrOk/cIlhjtfQPRzZZC6qYedCSvS1pphpxjb2rFM2BlSvNtZnxMx QkmrdL7N49wKiSDYa2w/N0fIvcyvALtMyC2tZsqmBiZlfWfiDkrWD9U8eSv+bUbxW+ZE A9EYgKzs8DdJvHCKzknwVIondw33YFpz3kAAXABJUd7XJ71Kspbp+9+Ot0zRVPTZWi+6 kp4PVgp4Q8KjWAo7azPR+Tkq/FH3ZFZ/7RFQYzqOrVpGAH3nIeTzIIj5Q/OoN1qxMkbX KeFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734345669; x=1734950469; 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=IboBFHnFjMRmj4U7b2A87R42I5K57Ju3A5WfXm90ceY=; b=Pkg36syT43Y+aVpGiUO8dTkvQhUPbJaqXxTn1pZyBuI6v9TUd9LEToSTGIi3oB/l4t 93Y1mPYgaTnR18G6Ec1QFr3v1gQ5ZY4hP30Wvq0709rTaSnm9TNtH5BftDM3NinuoLmA 5b+bVwYuYnooSjlDrwb+7HtIW6aJZEaxP0eQRuhKfMYc3PWk/0986h48IEfuExqdk4vH Utfsu4aNl43qHoAHJc0fk9nPMSEsRYktYkwuywqPZSK8uctdMXrXTxra+qIWbyNoNehj HpYKL9PJSB5JI1t0jYNChVbKeM0oVK27/Ws7Nzht1npFC0VF/mKXDiH7PyC0pOlRroqa ucPw== X-Forwarded-Encrypted: i=1; AJvYcCUeB7nst52Yovg8ONnvbVJPosV53HUpWAFoI0LZl/Gf5XPJclvJgk9Qy+mdWiFITHcWNzJWUQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz1/tTyl9P1lzzD8i4jxgK9F7W49+q49WZdb3KYXIo703CyPo9h uzIzL6PbJ5aj7+LqIJ7TsnBEnGNaFIclNvBrsn98KzH00qZ9Eh4JIgU99y7XkmQl0ynncvcRwHc v/MCHiLAaEqMIN4VcoxevznZhlEw= X-Gm-Gg: ASbGnct6X5Vp1LJ8qNs50ePs5MgdIr0Dx2xaxOiXUbAP3WmYEzM3L0FWb7V6S5ZMogR PtVGdl0jx7iOx7B8QEYG5evsmF8YvAtdLr01TbQ== X-Google-Smtp-Source: AGHT+IES19oHtkMp+0UJSQaQYFv5b/fo1nMqy9N5PPrCKxBiyE8W5a2pcHMF1tEXI3PZ0BqNrwlhRh9t+sJpTDdJPAg= X-Received: by 2002:a05:6122:1695:b0:516:2d4e:4493 with SMTP id 71dfb90a1353d-518ca218b0fmr10139466e0c.1.1734345669314; Mon, 16 Dec 2024 02:41:09 -0800 (PST) In-Reply-To: <544d13ee-54f0-4786-8c5b-b1c87570f36c@gmx.at> 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:297162 Archived-At: --000000000000898fd8062960d1af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM martin rudalics w= rote: > > 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 > --000000000000898fd8062960d1af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My expectation=C2=A0was that clone-frame, when frame-resize-pixelwise t,= would implicitly DTRT. I expect most people would have the same expectatio= n. Same as frameset-restore (now fixed with the patch).

When packages we use invoke clon= e-frame, we can't control their parameterization of those invocations w= ithout advice, so implied=C2=A0pixelwise=C2=A0seems wise. I added the expli= cit parameter more as awareness than anything else, but I imagine that care= fully-crafted pixelwise=C2=A0child frames in packages may want explicit pix= elwise clones if the authors aren't going to let-bind frame-resize-pixe= lwise around clone-frame calls. I'd prefer that we recommend that, actu= ally.
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 rudal= ics <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
--000000000000898fd8062960d1af--