From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: Question about pgtk -- is it meant to fix the disconnect crash bug? Date: Fri, 5 Mar 2021 12:35:11 -0800 Message-ID: References: <87h7lr4zrv.fsf@melete.silentflame.com> <83im66yujr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f5384d05bcd0055e" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27369"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuuki Harano , EMACS development team , Sean Whitton To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Mar 05 21:36:43 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lIHBi-0006zj-6I for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Mar 2021 21:36:42 +0100 Original-Received: from localhost ([::1]:52850 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIHBh-0006ZY-8b for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Mar 2021 15:36:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54426) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIHAV-0005jM-Cz for emacs-devel@gnu.org; Fri, 05 Mar 2021 15:35:27 -0500 Original-Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]:34940) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lIHAT-0000GU-EP; Fri, 05 Mar 2021 15:35:27 -0500 Original-Received: by mail-lf1-x12c.google.com with SMTP id e7so5836191lft.2; Fri, 05 Mar 2021 12:35:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5JC3MeR+Zikx+tgqHKqsYMXYht1zlLPVcReuCD+MlvY=; b=iUoqnQzSBtUqcoLyBkeb0CIpcTye0QKFlUF6qseW3h6uZGQy2yBPB9v5nlbvUxnToD TWqpVJucyZlNTxa3A8b/TmV5vxZlFT+veuLVQUim43VNdpzJtRcgkoWxEWV0xUCZ1L6W KHGGX8fWaJlMGLjqhs1BpXi0G804QYCHSTb1U/L6Rr+Q3WpxcwbFgjYd4JONnMA+AOZ6 ISiXhVP4FXEw5A0QfTTf2un9YY3VQo6wJAESk/wCa7RmGX4x8OtOPrngmle6Z4rc9SBi Oe7BrbYwdCyDbpGR4DInikYHRE41Qv1zEs9PZOLlILRSa+ike3/YinXi8imBWtT3aYmv oTCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5JC3MeR+Zikx+tgqHKqsYMXYht1zlLPVcReuCD+MlvY=; b=p8UD2BK/UIRDVirowbNjc5M05byoq0IgCQm6MYsZC3lEUHiDGsVlhLPkIBWM7dgn+L N1Lhj16wNsLj5ll8w7jPcidl8t5qXh4p/Ael2TngbpVlQ72CybzDbSsXtmX33mCCQj6U NXayQO2+xDFG0h0vIWFXuc47nTPZxn8pAAHmy8Y7+cYjV9w+6wf0bGCl4SrNURsCjza1 6FHGiP9DW3tAXIycOXcCDE14NTIkj0CM4E9EDNljnweHNZKngxLSNMrhgNA2RtQ2EfTE AvYZcnLUeqodqz8IPKRazAFJs76WH77IMNokfBX1+aeKy/IAXNCaGBZV/Jntijuyu8Tn zAPg== X-Gm-Message-State: AOAM530bm49W6CiLla9DC9GZlZ8AejQNS7RJ9pkxVQNug76yyxeBNxFp y49ozbmZYU+Z8cVPI5Z1D4rll6lhiTTGBXuIqF3H5tJJpb0= X-Google-Smtp-Source: ABdhPJz4TEaJimSyYHWAlAPkwJVnSMMY5I+jOD3NV8p43ku2GJBcpOgiAZu54RdoZ9nYjrVW0qRvouyrgs1PCrkR1Bk= X-Received: by 2002:a05:6512:36c9:: with SMTP id e9mr3902820lfs.556.1614976522728; Fri, 05 Mar 2021 12:35:22 -0800 (PST) In-Reply-To: <83im66yujr.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::12c; envelope-from=yandros@gmail.com; helo=mail-lf1-x12c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266043 Archived-At: --000000000000f5384d05bcd0055e Content-Type: text/plain; charset="UTF-8" On Thu, Mar 4, 2021 at 10:38 PM Eli Zaretskii wrote: > > From: chad > > Date: Thu, 4 Mar 2021 14:10:39 -0800 > > Cc: Yuuki Harano , > > EMACS development team > > > > I had thought that one of > > the benefits of the pgtk branch was that it would not have this bug, > > which plagues the old Emacs GTK builds. Am I just making that up? > > > > Adding a bit of historical perspective: it might be more accurate to say > "the GTK people are unwilling to > > address the issue when it's caused by what some people call 'unclean gtk > use' inside emacs", with the > > concomitant hope that they will more more receptive to a pure-gtk issue. > > Isn't the pgtk branch supposed to produce a "clean GTK use" inside > Emacs? I thought that was its purpose. > As I understand it, yes. This has the potential upsides of better integration and maybe a better fit for a theoretically post-X11 world. Another hopeful upside it "fewer years of Martin's life lost to frustration, etc". It might also help people find and solve the issue with gtk/gdk opening/closing/reopening display connections, but that doesn't seem certain to me: they asked for a simpler case than "all of emacs", and I'm not sure that "a different emacs" will be sufficient. I base this skepticism on the understanding that there is no doubt that the problem exists or (roughly) where, but rather that it is worth the required effort from the limited pool of people who are in position to do it. I can't help but notice that Wayland offers a potential "solution" by simply not supporting the underlying functionality that triggers the problem. In terms of "kicking the can down the road", the basic Wayland approach is "We're making something that you might use as a can. We do not promise that 'kicking' will apply to it, and explicitly disclaim any concept of 'road'." They're doing this to keep the problem more tractable; the emacs/gtk bug is one example of the sort of thing that they're explicitly labelling "Somebody Else's Problem". Again, I hope this helps, ~Chad --000000000000f5384d05bcd0055e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Mar 4, 2021 at 10:38 PM Eli Zaret= skii <eliz@gnu.org> wrote:
> From: chad <yandros@gmail.com&= gt;
> Date: Thu, 4 Mar 2021 14:10:39 -0800
> Cc: Yuuki Harano <masm+emacs@masm11.me>,
>=C2=A0 EMACS development team <emacs-devel@gnu.org>
>
>=C2=A0 I had thought that one of
>=C2=A0 the benefits of the pgtk branch was that it would not have this = bug,
>=C2=A0 which plagues the old Emacs GTK builds.=C2=A0 Am I just making t= hat up?
>
> Adding a bit of historical perspective: it might be more accurate to s= ay "the GTK people are unwilling to
> address the issue when it's caused by what some people call 'u= nclean gtk use' inside emacs", with the
> concomitant hope that they will more more receptive to a pure-gtk issu= e.

Isn't the pgtk branch supposed to produce a "clean GTK use" i= nside
Emacs?=C2=A0 I thought that was its purpose.

As I understand it, yes. This has the potential upsides of better int= egration and maybe a better fit for a theoretically post-X11 world.=C2=A0 A= nother hopeful upside it "fewer years of Martin's life lost to fru= stration, etc". It might also help people find and solve the issue wit= h gtk/gdk opening/closing/reopening display connections, but that doesn'= ;t seem certain to me: they asked for a simpler case than "all of emac= s", and I'm not sure that "a different emacs" will be su= fficient. I base this skepticism on the understanding that there is no doub= t that the problem exists or (roughly) where, but rather that it is worth t= he required effort from the limited pool of people who are in position to d= o it.

I can't help but notice that Wayland off= ers a potential "solution" by simply not supporting the underlyin= g functionality that triggers the problem. In terms of "kicking the ca= n down the road", the basic Wayland approach is "We're making= something that you might use as a can. We do not promise that 'kicking= ' will apply to it, and explicitly disclaim any concept of 'road= 9;." They're doing this to keep the problem more tractable; the em= acs/gtk bug is one example of the sort of thing that they're explicitly= labelling "Somebody Else's Problem".

Again, I hope this helps,
~Chad
--000000000000f5384d05bcd0055e--