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: Tue, 10 Dec 2024 11:24:12 -0500 Message-ID: References: <861pyfd8pe.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b2f8bf0628ecebb4" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38039"; 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 Tue Dec 10 17:30:37 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 1tL387-0009ff-Dq for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Dec 2024 17:30:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tL351-0001YA-9z; Tue, 10 Dec 2024 11:27:23 -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 1tL34g-0001M0-R6 for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2024 11:27:04 -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 1tL34g-00083v-8W for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2024 11:27: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=MnGsdYlHxGiboWFR3N3xVPM29jra3kXQXoUYioeGkRo=; b=nZE2fXsKkp6TzrHPqXnKWcGUTM7kwqpz9iXbI4A0sYIbX6omSNbHAxiHG+XihwGS+AN3xwAia+ME8qf4TOMR4U0fi8jec4csc3XKDboxOqcmKPrx89/Tz3Zegayhs4SJbzOEs3/fBmc1OdwL4CGazQDNb7UZbanteS29Um9IoqrdZhrFkHId9M1JsbxTIyjmphM9QlhCZGXSacBjYNgbrlhfIut6kH2pT9Dc58x4GvMROm7hSIw+xyZYLpafJbshVQyFOa8PMp6HpmJMIIHObcvNICMs6NEWFc+6ZuaRQoiQVm/ZdgsqIbrzJBKa797zfDnOIHUeL0mjWnNonFqYjQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tL34g-0003P0-29 for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2024 11:27: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: Tue, 10 Dec 2024 16:27: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.173384796912860 (code B ref 74750); Tue, 10 Dec 2024 16:27:02 +0000 Original-Received: (at 74750) by debbugs.gnu.org; 10 Dec 2024 16:26:09 +0000 Original-Received: from localhost ([127.0.0.1]:59259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tL33l-0003L5-D8 for submit@debbugs.gnu.org; Tue, 10 Dec 2024 11:26:09 -0500 Original-Received: from mail-ua1-f53.google.com ([209.85.222.53]:54570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tL33e-0003Jz-JU for 74750@debbugs.gnu.org; Tue, 10 Dec 2024 11:26:03 -0500 Original-Received: by mail-ua1-f53.google.com with SMTP id a1e0cc1a2514c-85bc5d0509bso1162694241.1 for <74750@debbugs.gnu.org>; Tue, 10 Dec 2024 08:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733847892; x=1734452692; 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=MnGsdYlHxGiboWFR3N3xVPM29jra3kXQXoUYioeGkRo=; b=Ml3fGIHsD8iyHg0Qo5aj/fUdYpI5DEc5ngwOkBD5wPC/0WMfJSW3CWsDvrsvJd/SqM F/yaqjQXJgepcfxEyxcGWGlG4Iw6AN8agp9yeoNhHmckHE9Jdi/oAH0mXm3Pa+G3NC4H YCmEKDu/qXdyvXoO7Q0UoLmE8uDoSjs8Znyv9G9PlxCRs+OecQYyBoGq+GZLimgMbncK 5FXOUyjH1GIr2LMKaLT9hp8nHyMfHiR6NWCIA9IR7RRifbCoScFMPFf1T+ATEtsCsX8e BgBi6uZlgh8QTgL4DpT7uCcRR3IXq+5NJpmLaZEptVdOuntPMoqsgr13oPyUOCF+9Q21 7U+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733847892; x=1734452692; 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=MnGsdYlHxGiboWFR3N3xVPM29jra3kXQXoUYioeGkRo=; b=q5eDAI47h5opQyrnk2+tdBqbG2kORXLgFZDEIONSOZTLiFZMpVXmrpmYmbcLpTL5pa pEebmtQfrJPxFlzCh+1au44pU+SIEvPsZ1DCLzN+Iw0G8M6bOR4p5x8VroEo38HGAF5N iClvT4ZS3XASr1L8oRjaSwht8aiZYP87b8uMHxB5otbVQj+nYupsS5bY7RP8Qctz/AOj qr039wdO9msc9RtgcWfIJbZMqeq5mOW4EwbPVh8GpeOPjYaB7/gzuS/C4H0+dVrew+1h ICkbLjXJTCcDJ2yAgI2A/xyk2GF614BzFHiEIOTN79tTEcoGRmO7jeGhfVzszKbjXXYE c4qQ== X-Forwarded-Encrypted: i=1; AJvYcCUdvktcuof/69j8DJehWj4QM5yftUBWo/cIRN1PvlNs+1Qlzva3Etx9vKqIlPlhTWAr1K+oww==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxYS0MPlSIId3Gsg6TnsdwtTAucildYsdKxO5XaISTvjWS+slpR exYd+UsbDilHMpcY6OJJaEHBVRrgI3zoanFCjbk4eDFPCScYVn77kLwAIx5gQmLv4hIVlD9gvvl 1Poq8IEgYErFVnfvq9oHJDZX1XUw= X-Gm-Gg: ASbGncukCubmWvppiK3QsTeeido8rSGtqJ9XSua3/Z1/MsZa7AZvbJ2zBSz3MhOdW+u woyg9xokBupVn6eDW/LouPZUnw93QhlBweOU= X-Google-Smtp-Source: AGHT+IE1RvS5rP/oQLp3H2cooRk/3z2j1RzIWPg3MnIArvBFxXCRshyfMwuyelYfIYpmFIBBicW7vwNQZIKIUx7v9PU= X-Received: by 2002:a05:6122:2399:b0:516:1ab5:fab0 with SMTP id 71dfb90a1353d-51888592cf9mr5130757e0c.12.1733847892029; Tue, 10 Dec 2024 08:24:52 -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:296767 Archived-At: --000000000000b2f8bf0628ecebb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 10, 2024 at 10:56=E2=80=AFAM martin rudalics = wrote: > >> clone-frame does not correctly clone frames on a pixelwise basis. > >> > >> make-frame's text-pixels geometry support does not produce specified > >> pixelwise geometry. This also impacts frameset-restore's ability to > >> precisely reproduce pixelwise frame sizes. > > This would be a bug in frameset.el. One problem I see is that > 'frame-resize-pixelwise' must be set "very early" when restoring a > session - at least _before_ the first time we send size hints to the > window manager. > The goal is, I think, to achieve pixelwise harmony among clone, make, and restore. FWIW, my GUI sessions always run with frame-resize-pixelwise set to t and see these sizing issues consistently. My reproducer is intended to engender the conversation as an illustration. I have resorted to manual labor to set frame sizes in various places and including squirreling away frame pixel size in frameset-save just to manually reset it after restoration due to text-pixel reliability issues. Somewhere in the bowels of frame.c, et.al., is an issue where text-pixels behaves differently than set-frame-size which is reliable on NS where make-frame using text-pixels is incorrect by the vertical scroll bar width. GTK it's off, too, but I didn't analyze that further. > >> I consider these to be related as clone-frame's use of make-frame > could be > >> using text-pixels but if that doesn't work then pixelwise cloning won= 't > >> work. I did read through the code base as best as I could but could n= ot > >> find the source of the text-pixels issue. > >> > >> The following reproducer, under -Q, shows the same results on 29.4 an= d > >> 30.0.92. My main platform is NS and I also did some testing on GTK. > GTK's > >> issues seem a bit "messier" and I didn't spend any time trying to > >> understand them in depth as I was more interested to know if GTK work= ed > >> correctly or not, which it doesn't. > > Your code binds 'frame-resize-pixelwise' temporarily. This cannot work > reliably. That variable should never change in an Emacs session because > its value affects the way we send size hint increments to the window > manager. > Again, this is just a reproducer for discussion and is intended to illustrate the issues, not to specifically discuss user habits for frame-resize-pixelwise across a GUI session. I think most people these days probably do have it set to t, even if it's become reflexive. This is, admittedly, a design error that would have to be fixed as > follows: > > - Implement a new frame parameter 'resize-pixelwise'. > I certainly prefer something more explicit such as this. - Send size hints according to the value of this parameter. When the > parameter is set, new size hints must be sent. > > Alternatively, we could send new size hints for all live frames whenever > 'frame-resize-pixelwise' is changed. This would have to be done with a > variable watcher. Still, let-binding this variable would confuse the > hell out of our interactions with the window manager. When the scope of > the let-binding is left, we would have to send size hints again. > No, please. >> This is an implementation of clone-frame that uses text-pixels under > >> make-frame. This depends on make-frame text-pixels being corrected. > Happy > >> to supply this as a patch should the discussion of these issues > progress in > >> that direction. > >> > >> (defun clone-frame (&optional frame no-windows pixelwise) > > What would the WM do in a situation where PIXELWISE is non-nil and > 'frame-resize-pixelwise' is nil? > The simple interim code (vs. the resize-pixelwise proposal) respects frame-resize-pixelwise as the user's preference. Same with being explicit by saying 'pixelwise, it's user intention. (when (and (display-graphic-p frame) (or pixelwise frame-resize-pixelwise)) FWIW, there are surely weird WM issues but at the very least, we're talking about the inner geometry text-width and text-height that Emacs controls and I stayed away from external geometry to start off at least seeing if we can correct for what Emacs controls completely. GTK is definitely worse than NS but at least in NS every user has the same experience as the WM options and behaviors are more constrained than X11-derived kind of free-for-all WMs. martin > --000000000000b2f8bf0628ecebb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Tue, Dec 10, 2024 at 10:56=E2=80=AFAM martin rudalics <rudalics@gmx.at> wrote:
=C2=A0>> clone-frame does not correctly clone fram= es on a pixelwise basis.
=C2=A0>>
=C2=A0>> make-frame's text-pixels geometry support does not produ= ce specified
=C2=A0>> pixelwise geometry. This also impacts frameset-restore's= ability to
=C2=A0>> precisely reproduce pixelwise frame sizes.

This would be a bug in frameset.el.=C2=A0 One problem I see is that
'frame-resize-pixelwise' must be set "very early" when re= storing a
session - at least _before_ the first time we send size hints to the
window manager.

The goal is, I think, to achieve=C2= =A0pixelwise harmony among clone,=C2=A0make,=C2=A0and restore. FWIW, my GUI= sessions always run with frame-resize-pixelwise=C2=A0set to t and see thes= e sizing issues consistently. My reproducer is intended to engender the con= versation as an illustration. I have resorted to manual labor to set frame = sizes in various places and including squirreling away frame pixel size in = frameset-save just to manually reset it after restoration due to text-pixel= reliability issues. Somewhere in the bowels of frame.c, et.al., is an issue where text-pixels behaves differently than s= et-frame-size which is reliable on NS where make-frame using text-pixels is= incorrect by the vertical scroll bar width. GTK it's off, too, but I d= idn't analyze that further.
=C2=A0
=C2=A0>> I consider these to be related as clone-frame's use of m= ake-frame could be
=C2=A0>> using text-pixels but if that doesn't work then pixelwis= e cloning won't
=C2=A0>> work. I did read through the code base as best as I could bu= t could not
=C2=A0>> find the source of the text-pixels issue.
=C2=A0>>
=C2=A0>> The following reproducer, under -Q, shows the same results o= n 29.4 and
=C2=A0>> 30.0.92. My main platform is NS and I also did some testing = on GTK. GTK's
=C2=A0>> issues seem a bit "messier" and I didn't spend= any time trying to
=C2=A0>> understand them in depth as I was more interested to know if= GTK worked
=C2=A0>> correctly or not, which it doesn't.

Your code binds 'frame-resize-pixelwise' temporarily.=C2=A0 This ca= nnot work
reliably.=C2=A0 That variable should never change in an Emacs session becau= se
its value affects the way we send size hint increments to the window
manager.

Again, this is just a reproducer for discussion = and is intended to illustrate the issues, not to specifically discuss user = habits for frame-resize-pixelwise=C2=A0across a GUI session. I think most p= eople these days probably do have it set to t, even if it's become refl= exive.
This is, admittedly, a design error that would have to be fixed as
follows:

- Implement a new frame parameter 'resize-pixelwise'.

I certainly prefer something more explicit such as this.

- Send size hints according to the value of this parameter.=C2=A0 When the<= br> =C2=A0 =C2=A0parameter is set, new size hints must be sent.

Alternatively, we could send new size hints for all live frames whenever 'frame-resize-pixelwise' is changed.=C2=A0 This would have to be do= ne with a
variable watcher.=C2=A0 Still, let-binding this variable would confuse the<= br> hell out of our interactions with the window manager.=C2=A0 When the scope = of
the let-binding is left, we would have to send size hints again.

No, please.

=C2=A0>> This is an implementation of clone-frame that uses text-pixe= ls under
=C2=A0>> make-frame. This depends on make-frame text-pixels being cor= rected. Happy
=C2=A0>> to supply this as a patch should the discussion of these iss= ues progress in
=C2=A0>> that direction.
=C2=A0>>
=C2=A0>> (defun clone-frame (&optional frame no-windows pixelwise= )

What would the WM do in a situation where PIXELWISE is non-nil and
'frame-resize-pixelwise' is nil?

The simple interi= m code (vs. the resize-pixelwise=C2=A0proposal) respects frame-resize-pixel= wise as the user's preference. Same with being explicit by saying '= pixelwise, it's user intention.

=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=A0(or pixelwise fram= e-resize-pixelwise))

FWIW, there are surely weird WM issues but at the very least, we= 9;re talking about the inner geometry text-width and text-height that Emacs= controls and I stayed away from external geometry to start off at least se= eing if we can correct for what Emacs controls completely. GTK is definitel= y worse than NS but at least in NS every user has the same experience as th= e WM options and behaviors are more constrained than X11-derived kind of fr= ee-for-all WMs.

martin
--000000000000b2f8bf0628ecebb4--