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: Fri, 13 Dec 2024 13:25:03 -0500 Message-ID: References: <861pyfd8pe.fsf@gnu.org> <4d057282-8ec2-4ddb-ac0f-23e65af6e5a1@gmx.at> <7404039b-e71e-44e5-a446-70fa07889528@gmx.at> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a4265106292af5a6" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10179"; 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 Fri Dec 13 19:28:19 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 1tMAOh-0002Sm-7Q for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 13 Dec 2024 19:28:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMAOU-000179-Eb; Fri, 13 Dec 2024 13:28:06 -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 1tMAOR-000170-KQ for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2024 13:28: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 1tMAOR-0005Gt-1P for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2024 13:28: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=VmpMqJkvXpfUNvo9Gtbov5U+IKlho6u+i0GYwPH4Y1s=; b=ioqh8dlFwneysZ+DkhBnYGisKKGi0lrJn1R8k0utJAtZpXDmHHXkRaOeo57EfoxrMKvqBXETJavnBRvLS0qwaDR/B13NtybPXXeNzz/l6781QaiBV87M9nrgiS3z1BcuanHEyvi0SjZCeZ+tMtPAJQuk7oERH2iv0Qjt0+rDyoMvizNDM0el62AvxxvXFvKkPyjc+RgqAVC/uhTni5e1N7Ww2wFSdQRaYceZzgtQj/LXkWqKB1/LQE9dERl3qBY52ZY1kJjuHkRFdjgVYv2wqxj0NSZmRvPfskRdUkQ3WXqctmX6SFVMK4NWzCzTJceduTGxeSs9vOf+Qo8d6YpI0w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tMAOQ-0004dj-Ii for bug-gnu-emacs@gnu.org; Fri, 13 Dec 2024 13:28: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: Fri, 13 Dec 2024 18:28: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.173411442617758 (code B ref 74750); Fri, 13 Dec 2024 18:28:02 +0000 Original-Received: (at 74750) by debbugs.gnu.org; 13 Dec 2024 18:27:06 +0000 Original-Received: from localhost ([127.0.0.1]:44071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tMANO-0004bu-Or for submit@debbugs.gnu.org; Fri, 13 Dec 2024 13:27:06 -0500 Original-Received: from mail-vk1-f170.google.com ([209.85.221.170]:48548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tMANI-0004bU-HT for 74750@debbugs.gnu.org; Fri, 13 Dec 2024 13:26:57 -0500 Original-Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-518957b0533so562479e0c.1 for <74750@debbugs.gnu.org>; Fri, 13 Dec 2024 10:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734114347; x=1734719147; 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=VmpMqJkvXpfUNvo9Gtbov5U+IKlho6u+i0GYwPH4Y1s=; b=dvleoEhWiF5PhT/DtIxoSQoZfoMV8TCmXwSSK/dtjp8tOz/zoJYvh/oTs2Ipe2n7Z7 4YYg12xIS9KaGXZPPboMORsvZFy01YlbvoDR+5Y2yE0R40dmClV7ZhqcuYU9ppO6fiwo e9VmdfpfydDwnTopuKamimJV3QqyATMXYyy3d/5O7pxFfgByvn8NDTj3XlUKaCIk7103 RtxnAjKVbHuOIQzFXxtY9X5bJaiqMXZgZJgBnPkXZiUJFJ6xCwsPauZ8aa+JQLuO+sY7 UaSrizbCsKRlivSPvu7k6q6s3Mu5ZPezmsG4eJkO1jkDhTIn8sTmPmITGoFJu2wwT3UI lGzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734114347; x=1734719147; 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=VmpMqJkvXpfUNvo9Gtbov5U+IKlho6u+i0GYwPH4Y1s=; b=bJWN6ArhCPh4JHKN86aamrZbu4qzvZ5sJhKCHKVgtMRggRvGCP5KlMljAQedv+Zh1/ 03IrLqRxeGPnPVQGjUVeT00jKOV6BEbM5C4F+24gXxiRLJicoVNgUqYe43DZqG/pd/rY kFplWNq2DcSxe6IY/U7RhxYCc1lVLy17hs/P5IOEzdBKHSIPIWuoy90VHoqPHRuw1JNb ZymRItmr6lwUqIlO5bZHgun6Y1lgPMBA6d3t7RgO0yhkT6/8VXcU14IH6oULACwfrJuk GodCLqtjmiD7QAxfr9dNs7T8KrIVrKhVNS5eEtC+P6Ff1xIAFm4dCo5jlphx2d9EnaBM szkg== X-Forwarded-Encrypted: i=1; AJvYcCXxMyaJkg1pa4ZFgGRlEEAyISurgndj/Z/0f3d+/u3DFFaNhyuGa2MGmrePCzZV9smZ2Lusjg==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yx+HSUuEDllZ5LwrN3M2oWz2EuUERKLd8uXEqUL9hp+SsVY0ttN rAgNcQI4rjUOUOwlc0Pg1y0aWCv/aMXbltOIEMz9db77CH93Xuss8C0aC3WMXDroOboL0aqAJcO ZZtI7cenWzhwpVOXUkSmpkOofhjk= X-Gm-Gg: ASbGncvS6iKO1u+w5axJkfCTUBAQCCMsQCh05BSw0eTYJGcMWAhZcDFTaZtiDOuVbbN SThTDt8M2S6ECbZNnrthNonjjsW+vBDSXCRjHjQ== X-Google-Smtp-Source: AGHT+IHjk4Q8+oR/Gn3S+2CX0NyUDtsD3r4cbRCDfDYXJmDumaL04t/C6SzLhb+GnbQY8HoySuxz64HbC1pu2aTdQco= X-Received: by 2002:a05:6122:4592:b0:517:4fca:86d4 with SMTP id 71dfb90a1353d-518ca48b577mr3971334e0c.11.1734114346802; Fri, 13 Dec 2024 10:25:46 -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:296989 Archived-At: --000000000000a4265106292af5a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 13, 2024 at 1:15=E2=80=AFPM martin rudalics w= rote: > > Thank you for the patch and continued focus on this. The following is > the > > behavior I see on NS with the patch applied with target width 1700 and > > height 1000. These are results from clone-frame using text-pixels whic= h > > I've included below without explicit pixelwise argument so it respects > > frame-resize-pixelwise. > > Thank you for conducting these experiments. > My pleasure, actually. I live inside Emacs so the better we make it for us the better for all. > Note: frame-inhibit-implied-resize=3D(tab-bar-lines) is the default sett= ing > > on NS: > > > > #if defined (USE_GTK) || defined (HAVE_NS) > > frame_inhibit_implied_resize =3D list1 (Qtab_bar_lines); > > > > frame-resize-pixelwise=3Dnil frame-inhibit-implied-resize=3Dnil > text-width=3D1692 > > (=CE=94-8) text-height=3D984 (=CE=94-16) native-width=3D1727 (=CE=94-8= ) native-height 988 > > (=CE=94-16) > > > > Result: respects lines/cols as expected. > > It's problematic to clone a frame made with 'frame-resize-pixelwise' > non-nil in a setting with 'frame-resize-pixelwise' nil. I always have > 'frame-resize-pixelwise' t and never change it. > As you pointed out, these are experiments and reflect the desire to fully understand (and control) Emacs behavior under various circumstances we encounter. > > frame-resize-pixelwise=3Dt frame-inhibit-implied-resize=3D(tab-bar-lin= es) > > text-width=3D1700 (=CE=940) text-height=3D1000 (=CE=940) native-width= =3D1735 (=CE=940) > > native-height 1004 (=CE=940) > > > > Result: Okay by accident, I think, only because tab-bar-lines paramete= r > is > > nil during adjust_frame_height invocations? > > adjust_frame_size you mean, I suppose. Does your frame have a tab bar? > Yes, typo. These results are all under -Q as we need to repro, so no visible tab bar, just the default NS view which is the tool bar which under master, now appears on the title bar. Something I didn't notice until today but it's neither here nor there, I suppose. I disable tool-bar under all my own real-world circumstances. > frame-resize-pixelwise=3Dt frame-inhibit-implied-resize=3Dnil text-width= =3D1700 > > (=CE=940) text-height=3D1000 (=CE=940) native-width=3D1735 (=CE=940) n= ative-height 1004 > (=CE=940) > > > > Result: Okay but with frame-inhibit-implied-resize nil, I'd have > expected > > rows/cols vs. pixelwise. > > Why? 'frame-inhibit-implied-resize' is about _not_ resizing a frame's > window when one removes/adds one of the items it mentions. It should > work with pixelwise and normal resizing. > I said that because the latest patch respects frame-inhibit-implied-resize not frame-resize-pixelwise. > frame-resize-pixelwise=3Dt frame-inhibit-implied-resize=3Dt text-width= =3D1685 > > (=CE=94-15) text-height=3D1000 (=CE=940) native-width=3D1720 (=CE=94-1= 5) native-height 1004 > > (=CE=940) > > > > Result: I think this case remains broken needing the adjustment from > your > > first patch that you wanted to also account for fringes? > > 15 is an odd number so it can't be the default fringes. IIUC it's your > scroll bar which gets set up after the "frame was made" and while > resizing is inhibited. Note that the fringes are purely Emacs internal > - we can set them up any way we like. The scroll bar is more difficult > since the toolkit usually determines its default width. You could try > to debug this with a breakpoint in 'gui_set_scroll_bar_width' and after > that one in 'frame_inhibit_resize'. Here on xfwm/GTK-3 the text width > remains unchanged. > Indeed 15 is the vertical scroll bar width. This was what I reported in the original bug submission. You suggested a patch that would accommodate fringes, et.al. If you'd like me to make adjustments; e.g., resizing fringes or whatever, happy to do it and rerun. These are all ostensively calls to clone-frame. I'd expect, as I guess most people would, that cloning produces the precise geometry of the originating frame, scroll bar or not. > > My default GUI setup is frame-resize-pixelwise t > > frame-inhibit-implied-resize t as I expect many people have adopted > these > > days. > > Few people have AFAICT. Note that all these experiments are borderline. > Cloning a frame should respect the settings that were active at the time > the original was made. We can try to make it behave reasonably when > these values change but I am not sure whether we will succeed. > Let's try. -Stephane --000000000000a4265106292af5a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Fri, Dec 13, 2024 at 1:15=E2=80=AFPM martin rudalics <rudalics@gmx.at> wrote:
=C2=A0> Thank you for the patch and continued focus on= this. The following is the
=C2=A0> behavior I see on NS with the patch applied with target width 17= 00 and
=C2=A0> height 1000. These are results from clone-frame using text-pixel= s which
=C2=A0> I've included below without explicit pixelwise argument so i= t respects
=C2=A0> frame-resize-pixelwise.

Thank you for conducting these experiments.

=
My pleasure, a= ctually. I live inside=C2=A0Emacs so the better we make it for us the bette= r for all.

=C2=A0> Note: frame-inhibit-implied-resize=3D(tab-bar-lines) is the defa= ult setting
=C2=A0> on NS:
=C2=A0>
=C2=A0> #if defined (USE_GTK) || defined (HAVE_NS)
=C2=A0>=C2=A0 =C2=A0 frame_inhibit_implied_resize =3D list1 (Qtab_bar_li= nes);
=C2=A0>
=C2=A0> frame-resize-pixelwise=3Dnil frame-inhibit-implied-resize=3Dnil = text-width=3D1692
=C2=A0> (=CE=94-8) text-height=3D984 (=CE=94-16) native-width=3D1727 (= =CE=94-8) native-height 988
=C2=A0> (=CE=94-16)
=C2=A0>
=C2=A0> Result: respects lines/cols as expected.

It's problematic to clone a frame made with 'frame-resize-pixelwise= '
non-nil in a setting with 'frame-resize-pixelwise' nil.=C2=A0 I alw= ays have
'frame-resize-pixelwise' t and never change it.

As you pointed out, these are experiments and reflect the desire to full= y understand (and control) Emacs behavior under various circumstances we en= counter.
=C2=A0
=C2=A0> frame-resize-pixelwise=3Dt frame-inhibit-implied-resize=3D(tab-b= ar-lines)
=C2=A0> text-width=3D1700 (=CE=940) text-height=3D1000 (=CE=940) native-= width=3D1735 (=CE=940)
=C2=A0> native-height 1004 (=CE=940)
=C2=A0>
=C2=A0> Result: Okay by accident, I think, only because tab-bar-lines pa= rameter is
=C2=A0> nil during adjust_frame_height invocations?

adjust_frame_size you mean, I suppose.=C2=A0 Does your frame have a tab bar= ?

Yes, typo. These results are all under -Q as we nee= d to repro, so no visible tab bar, just the default NS view which is the to= ol bar which under master, now appears on the title bar. Something I didn&#= 39;t notice until today but it's neither here nor there, I suppose. I d= isable tool-bar under all my own real-world circumstances.

=C2=A0> frame-resize-pixelwise=3Dt frame-inhibit-implied-resize=3Dnil te= xt-width=3D1700
=C2=A0> (=CE=940) text-height=3D1000 (=CE=940) native-width=3D1735 (=CE= =940) native-height 1004 (=CE=940)
=C2=A0>
=C2=A0> Result: Okay but with frame-inhibit-implied-resize nil, I'd = have expected
=C2=A0> rows/cols vs. pixelwise.

Why?=C2=A0 'frame-inhibit-implied-resize' is about _not_ resizing a= frame's
window when one removes/adds one of the items it mentions.=C2=A0 It should<= br> work with pixelwise and normal resizing.

I said that becau= se the latest patch respects frame-inhibit-implied-resize not frame-resize-= pixelwise.

=C2=A0> frame-resize-pixelwise=3Dt frame-inhibit-implied-resize=3Dt text= -width=3D1685
=C2=A0> (=CE=94-15) text-height=3D1000 (=CE=940) native-width=3D1720 (= =CE=94-15) native-height 1004
=C2=A0> (=CE=940)
=C2=A0>
=C2=A0> Result: I think this case remains broken needing the adjustment = from your
=C2=A0> first patch that you wanted to also account for fringes?

15 is an odd number so it can't be the default fringes.=C2=A0 IIUC it&#= 39;s your
scroll bar which gets set up after the "frame was made" and while=
resizing is inhibited.=C2=A0 Note that the fringes are purely Emacs interna= l
- we can set them up any way we like.=C2=A0 The scroll bar is more difficul= t
since the toolkit usually determines its default width.=C2=A0 You could try=
to debug this with a breakpoint in 'gui_set_scroll_bar_width' and a= fter
that one in 'frame_inhibit_resize'.=C2=A0 Here on xfwm/GTK-3 the te= xt width
remains unchanged.

Indeed 15 is the vertical scroll b= ar width. This was what I reported in the original bug submission. You sugg= ested a patch that would accommodate fringes, et.a= l. If you'd like me to make adjustments; e.g., resizing fringes or = whatever, happy to do it and rerun.

These are all ostensively calls to clone-frame. I= 9;d expect, as I guess most people would, that cloning produces the precise= geometry of the originating frame, scroll bar or not.
=C2= =A0
=C2=A0> My default GUI setup is frame-resize-pixelwise t
=C2=A0> frame-inhibit-implied-resize t as I expect many people have adop= ted these
=C2=A0> days.

Few people have AFAICT.=C2=A0 Note that all these experiments are borderlin= e.
Cloning a frame should respect the settings that were active at the time the original was made.=C2=A0 We can try to make it behave reasonably when these values change but I am not sure whether we will succeed.

Let's try.

-Stephane
--000000000000a4265106292af5a6--