* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. [not found] ` <20220406023058.315C7C009A8@vcs2.savannah.gnu.org> @ 2022-04-06 15:37 ` Sean Whitton 2022-04-06 15:44 ` Robert Pluim 2022-04-07 0:28 ` Po Lu 0 siblings, 2 replies; 17+ messages in thread From: Sean Whitton @ 2022-04-06 15:37 UTC (permalink / raw) To: Po Lu, emacs-devel Hello, On Tue 05 Apr 2022 at 10:30pm -04, Po Lu via Mailing list for Emacs changes wrote: > diff --git a/src/emacs.c b/src/emacs.c > index 2a4dcc2c2c..acb409fcb7 100644 > --- a/src/emacs.c > +++ b/src/emacs.c > @@ -1734,12 +1734,25 @@ main (int argc, char **argv) > sockfd = SD_LISTEN_FDS_START; > #endif /* HAVE_LIBSYSTEMD */ > > -#ifdef USE_GTK > + /* On X, the bug happens because we call abort to avoid GLib > + crashes upon a longjmp in our X error handler. > + > + On PGTK, GTK calls exit in its own error handlers for either > + X or Wayland. Display different messages depending on the > + window system to avoid referring users to the wrong GTK bug > + report. */ > +#ifdef HAVE_PGTK > + fputs ("Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a" > + "display connection is closed." > + "\nThere is no way to fix this problem, so if you want to use Emacs on Wayland" > + "on multiple displays and have Emacs survive disconnects, you lose.", Nice idea to avoid referring users to a bug report that doesn't apply to pgtk. But is there truly "no way to fix this problem" in the pgtk case too? Is it really that fundamental to the design of GTK3? -- Sean Whitton ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-06 15:37 ` master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK Sean Whitton @ 2022-04-06 15:44 ` Robert Pluim 2022-04-06 18:45 ` Sean Whitton 2022-04-07 0:28 ` Po Lu 1 sibling, 1 reply; 17+ messages in thread From: Robert Pluim @ 2022-04-06 15:44 UTC (permalink / raw) To: Sean Whitton; +Cc: Po Lu, emacs-devel >>>>> On Wed, 06 Apr 2022 08:37:20 -0700, Sean Whitton <spwhitton@spwhitton.name> said: >> +#ifdef HAVE_PGTK >> + fputs ("Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a" >> + "display connection is closed." >> + "\nThere is no way to fix this problem, so if you want to use Emacs on Wayland" >> + "on multiple displays and have Emacs survive disconnects, you lose.", Sean> Nice idea to avoid referring users to a bug report that doesn't apply to Sean> pgtk. But is there truly "no way to fix this problem" in the pgtk case Sean> too? Is it really that fundamental to the design of GTK3? There is no way for *emacs* to fix this problem. The GTK guys have been sitting on it for 15 years. Iʼm sure they could fix it if they wanted to. Robert -- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-06 15:44 ` Robert Pluim @ 2022-04-06 18:45 ` Sean Whitton 2022-04-06 20:12 ` Óscar Fuentes 0 siblings, 1 reply; 17+ messages in thread From: Sean Whitton @ 2022-04-06 18:45 UTC (permalink / raw) To: Robert Pluim; +Cc: Po Lu, emacs-devel Hello, On Wed 06 Apr 2022 at 05:44PM +02, Robert Pluim wrote: >>>>>> On Wed, 06 Apr 2022 08:37:20 -0700, Sean Whitton <spwhitton@spwhitton.name> said: > >> +#ifdef HAVE_PGTK > >> + fputs ("Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a" > >> + "display connection is closed." > >> + "\nThere is no way to fix this problem, so if you want to use Emacs on Wayland" > >> + "on multiple displays and have Emacs survive disconnects, you lose.", > > Sean> Nice idea to avoid referring users to a bug report that doesn't apply to > Sean> pgtk. But is there truly "no way to fix this problem" in the pgtk case > Sean> too? Is it really that fundamental to the design of GTK3? > > There is no way for *emacs* to fix this problem. The GTK guys have > been sitting on it for 15 years. Iʼm sure they could fix it if they > wanted to. That is my understanding of the X11 bug, but the change made me think that the status of the bug as it applies to pgtk might be subtly different. -- Sean Whitton ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-06 18:45 ` Sean Whitton @ 2022-04-06 20:12 ` Óscar Fuentes 2022-04-07 0:32 ` Po Lu 0 siblings, 1 reply; 17+ messages in thread From: Óscar Fuentes @ 2022-04-06 20:12 UTC (permalink / raw) To: emacs-devel Sean Whitton <spwhitton@spwhitton.name> writes: > Hello, > > On Wed 06 Apr 2022 at 05:44PM +02, Robert Pluim wrote: > >>>>>>> On Wed, 06 Apr 2022 08:37:20 -0700, Sean Whitton <spwhitton@spwhitton.name> said: >> >> +#ifdef HAVE_PGTK >> >> + fputs ("Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a" >> >> + "display connection is closed." >> >> + "\nThere is no way to fix this problem, so if you want to use Emacs on Wayland" >> >> + "on multiple displays and have Emacs survive disconnects, you lose.", >> >> Sean> Nice idea to avoid referring users to a bug report that doesn't apply to >> Sean> pgtk. But is there truly "no way to fix this problem" in the pgtk case >> Sean> too? Is it really that fundamental to the design of GTK3? >> >> There is no way for *emacs* to fix this problem. The GTK guys have >> been sitting on it for 15 years. Iʼm sure they could fix it if they >> wanted to. > > That is my understanding of the X11 bug, but the change made me think > that the status of the bug as it applies to pgtk might be subtly > different. Is it possible at all to use the PGTK port on multiple graphical displays? Wayland does not provide network transparency. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-06 20:12 ` Óscar Fuentes @ 2022-04-07 0:32 ` Po Lu 0 siblings, 0 replies; 17+ messages in thread From: Po Lu @ 2022-04-07 0:32 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Óscar Fuentes <ofv@wanadoo.es> writes: > Is it possible at all to use the PGTK port on multiple graphical > displays? Wayland does not provide network transparency. X isn't network-transparent for the same reasons Wayland isn't: DRI2, DRI3, GLX (unless you use indirect rendering) and MIT-SHM are not network transparent. That doesn't mean the entire protocol can be discarded as "not network transparent", and with various small proxies both X and Wayland can be made completely network transparent. Besides, you can run multiple Wayland displays locally as well. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-06 15:37 ` master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK Sean Whitton 2022-04-06 15:44 ` Robert Pluim @ 2022-04-07 0:28 ` Po Lu 2022-04-07 0:49 ` Sean Whitton 1 sibling, 1 reply; 17+ messages in thread From: Po Lu @ 2022-04-07 0:28 UTC (permalink / raw) To: Sean Whitton; +Cc: emacs-devel Sean Whitton <spwhitton@spwhitton.name> writes: > Nice idea to avoid referring users to a bug report that doesn't apply to > pgtk. But is there truly "no way to fix this problem" in the pgtk case > too? Is it really that fundamental to the design of GTK3? Yes, 100%. GDK just calls `_exit' on an IO error. You cannot even run an atexit handler. And since we don't have control over Xlib when built with PGTK, there's no way to run code before GDK's own IO error handler either. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-07 0:28 ` Po Lu @ 2022-04-07 0:49 ` Sean Whitton 2022-04-07 1:02 ` Po Lu 2022-04-07 2:11 ` Stefan Monnier 0 siblings, 2 replies; 17+ messages in thread From: Sean Whitton @ 2022-04-07 0:49 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 787 bytes --] Hello, On Thu 07 Apr 2022 at 08:28am +08, Po Lu wrote: > Sean Whitton <spwhitton@spwhitton.name> writes: > >> Nice idea to avoid referring users to a bug report that doesn't apply to >> pgtk. But is there truly "no way to fix this problem" in the pgtk case >> too? Is it really that fundamental to the design of GTK3? > > Yes, 100%. GDK just calls `_exit' on an IO error. You cannot even run > an atexit handler. > > And since we don't have control over Xlib when built with PGTK, there's > no way to run code before GDK's own IO error handler either. Thanks. I'd like to install the attached patch to preempt questions like mine; any objections? I still have some stuff in my init.el based on the hope that this could be fixed; I'll probably remove it now :( -- Sean Whitton [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-src-emacs.c-main-Say-that-the-problem-is-fundamental.patch --] [-- Type: text/x-diff, Size: 1119 bytes --] From adecae1728630541286b4a83406e3c863e0c8f4c Mon Sep 17 00:00:00 2001 From: Sean Whitton <spwhitton@spwhitton.name> Date: Wed, 6 Apr 2022 17:45:55 -0700 Subject: [PATCH] ; * src/emacs.c (main): Say that the problem is fundamental to GTK. --- src/emacs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/emacs.c b/src/emacs.c index acb409fcb7..79f4f54f6f 100644 --- a/src/emacs.c +++ b/src/emacs.c @@ -1744,8 +1744,8 @@ main (int argc, char **argv) #ifdef HAVE_PGTK fputs ("Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a" "display connection is closed." - "\nThere is no way to fix this problem, so if you want to use Emacs on Wayland" - "on multiple displays and have Emacs survive disconnects, you lose.", + "\nThe limitation is fundamental to GTK on Wayland, so Emacs on Wayland" + "with multiple displays is unlikely ever to be able to survive disconnections.", stderr); #elif defined USE_GTK fputs ("\nWarning: due to a long standing Gtk+ bug\nhttps://gitlab.gnome.org/GNOME/gtk/issues/221\n\ -- 2.30.2 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-07 0:49 ` Sean Whitton @ 2022-04-07 1:02 ` Po Lu 2022-04-07 2:11 ` Stefan Monnier 1 sibling, 0 replies; 17+ messages in thread From: Po Lu @ 2022-04-07 1:02 UTC (permalink / raw) To: Sean Whitton; +Cc: emacs-devel Sean Whitton <spwhitton@spwhitton.name> writes: > Thanks. I'd like to install the attached patch to preempt questions > like mine; any objections? I still have some stuff in my init.el based > on the hope that this could be fixed; I'll probably remove it now :( No objections here, if nobody else has any I'll install this. Thanks. > From adecae1728630541286b4a83406e3c863e0c8f4c Mon Sep 17 00:00:00 2001 > From: Sean Whitton <spwhitton@spwhitton.name> > Date: Wed, 6 Apr 2022 17:45:55 -0700 > Subject: [PATCH] ; * src/emacs.c (main): Say that the problem is fundamental > to GTK. > > --- > src/emacs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/emacs.c b/src/emacs.c > index acb409fcb7..79f4f54f6f 100644 > --- a/src/emacs.c > +++ b/src/emacs.c > @@ -1744,8 +1744,8 @@ main (int argc, char **argv) > #ifdef HAVE_PGTK > fputs ("Due to a limitation in GTK 3, Emacs built with PGTK will simply exit when a" > "display connection is closed." > - "\nThere is no way to fix this problem, so if you want to use Emacs on Wayland" > - "on multiple displays and have Emacs survive disconnects, you lose.", > + "\nThe limitation is fundamental to GTK on Wayland, so Emacs on Wayland" > + "with multiple displays is unlikely ever to be able to survive disconnections.", > stderr); > #elif defined USE_GTK > fputs ("\nWarning: due to a long standing Gtk+ bug\nhttps://gitlab.gnome.org/GNOME/gtk/issues/221\n\ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-07 0:49 ` Sean Whitton 2022-04-07 1:02 ` Po Lu @ 2022-04-07 2:11 ` Stefan Monnier 2022-04-07 2:45 ` Po Lu 1 sibling, 1 reply; 17+ messages in thread From: Stefan Monnier @ 2022-04-07 2:11 UTC (permalink / raw) To: Sean Whitton; +Cc: Po Lu, emacs-devel >>> Nice idea to avoid referring users to a bug report that doesn't apply to >>> pgtk. But is there truly "no way to fix this problem" in the pgtk case >>> too? Is it really that fundamental to the design of GTK3? >> >> Yes, 100%. GDK just calls `_exit' on an IO error. You cannot even run >> an atexit handler. >> >> And since we don't have control over Xlib when built with PGTK, there's >> no way to run code before GDK's own IO error handler either. > > Thanks. I'd like to install the attached patch to preempt questions > like mine; any objections? I still have some stuff in my init.el based > on the hope that this could be fixed; I'll probably remove it now :( FWIW, I think "fundamental" is a bit strong here. I don't see any evidence that the design of the API makes it impossible. It seems more like a problem with the current implementation or a problem fixable with the addition of a couple new functions/hooks in the API. Stefan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-07 2:11 ` Stefan Monnier @ 2022-04-07 2:45 ` Po Lu 2022-04-07 3:16 ` Stefan Monnier 0 siblings, 1 reply; 17+ messages in thread From: Po Lu @ 2022-04-07 2:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: Sean Whitton, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > FWIW, I think "fundamental" is a bit strong here. I don't see any > evidence that the design of the API makes it impossible. It seems more > like a problem with the current implementation I think the problem is quite fundamental to the current implementation of GDK: lots of stuff is left unfreed when a display is programmatically disconnected as-is, and freeing even that typically requires a working connection to the display server. Which is unattainable when a display disconnects due to an IO error. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-07 2:45 ` Po Lu @ 2022-04-07 3:16 ` Stefan Monnier 2022-04-07 5:32 ` Sean Whitton 0 siblings, 1 reply; 17+ messages in thread From: Stefan Monnier @ 2022-04-07 3:16 UTC (permalink / raw) To: Po Lu; +Cc: Sean Whitton, emacs-devel >> FWIW, I think "fundamental" is a bit strong here. I don't see any >> evidence that the design of the API makes it impossible. It seems more >> like a problem with the current implementation > I think the problem is quite fundamental to the current implementation > of GDK: Fundamental to the implementation means that it can be fixed without changing the design of the API ;-) > lots of stuff is left unfreed when a display is programmatically > disconnected as-is, and freeing even that typically requires a working > connection to the display server. Which is unattainable when a display > disconnects due to an IO error. I suspect it's worse than that, since "left unfreed" would just lead to memory leaks, which I suspect could be tolerable (and in any case much better than what we have now). Stefan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-07 3:16 ` Stefan Monnier @ 2022-04-07 5:32 ` Sean Whitton 2022-04-07 23:04 ` Stefan Monnier 0 siblings, 1 reply; 17+ messages in thread From: Sean Whitton @ 2022-04-07 5:32 UTC (permalink / raw) To: Stefan Monnier, Po Lu; +Cc: emacs-devel Hello, On Wed 06 Apr 2022 at 11:16pm -04, Stefan Monnier wrote: >>> FWIW, I think "fundamental" is a bit strong here. I don't see any >>> evidence that the design of the API makes it impossible. It seems more >>> like a problem with the current implementation >> I think the problem is quite fundamental to the current implementation >> of GDK: > > Fundamental to the implementation means that it can be fixed without > changing the design of the API ;-) I do see what you mean -- and please do suggest another word if you have one in mind -- but in this case I am not sure the distinction between fundamental-to-the-API and fundamental-to-the-implementation matters. The problem is in a different class to just a bug that upstream doesn't seem very motivated to fix, and that matters from a user's point of view. -- Sean Whitton ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-07 5:32 ` Sean Whitton @ 2022-04-07 23:04 ` Stefan Monnier 2022-04-08 4:09 ` Sean Whitton 0 siblings, 1 reply; 17+ messages in thread From: Stefan Monnier @ 2022-04-07 23:04 UTC (permalink / raw) To: Sean Whitton; +Cc: Po Lu, emacs-devel >> Fundamental to the implementation means that it can be fixed without >> changing the design of the API ;-) > I do see what you mean -- and please do suggest another word if you have > one in mind -- but in this case I am not sure the distinction between > fundamental-to-the-API and fundamental-to-the-implementation matters. Maybe "difficult to fix"? Stefan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-07 23:04 ` Stefan Monnier @ 2022-04-08 4:09 ` Sean Whitton 2022-04-08 5:29 ` Sean Whitton 0 siblings, 1 reply; 17+ messages in thread From: Sean Whitton @ 2022-04-08 4:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: Po Lu, emacs-devel Hello, On Thu 07 Apr 2022 at 07:04PM -04, Stefan Monnier wrote: >>> Fundamental to the implementation means that it can be fixed without >>> changing the design of the API ;-) >> I do see what you mean -- and please do suggest another word if you have >> one in mind -- but in this case I am not sure the distinction between >> fundamental-to-the-API and fundamental-to-the-implementation matters. > > Maybe "difficult to fix"? Cool, thanks, pushed that. -- Sean Whitton ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-08 4:09 ` Sean Whitton @ 2022-04-08 5:29 ` Sean Whitton 2022-04-08 6:13 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Sean Whitton @ 2022-04-08 5:29 UTC (permalink / raw) To: emacs-devel Hello, On Thu 07 Apr 2022 at 09:09pm -07, Sean Whitton wrote: > Cool, thanks, pushed that. This was the first thing I've ever pushed myself, but it seems it didn't make it to emacs-diffs. Something DKIM-related? -- Sean Whitton ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-08 5:29 ` Sean Whitton @ 2022-04-08 6:13 ` Eli Zaretskii 2022-04-08 14:06 ` Sean Whitton 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2022-04-08 6:13 UTC (permalink / raw) To: Sean Whitton; +Cc: emacs-devel > From: Sean Whitton <spwhitton@spwhitton.name> > Date: Thu, 07 Apr 2022 22:29:20 -0700 > > Hello, > > On Thu 07 Apr 2022 at 09:09pm -07, Sean Whitton wrote: > > > Cool, thanks, pushed that. > > This was the first thing I've ever pushed myself, but it seems it didn't > make it to emacs-diffs. Something DKIM-related? No. Emacs-diffs employs moderation. So that's normal (for the first time you install changes), and was already taken care of for your case. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK. 2022-04-08 6:13 ` Eli Zaretskii @ 2022-04-08 14:06 ` Sean Whitton 0 siblings, 0 replies; 17+ messages in thread From: Sean Whitton @ 2022-04-08 14:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Hello, On Fri 08 Apr 2022 at 09:13am +03, Eli Zaretskii wrote: > No. Emacs-diffs employs moderation. So that's normal (for the first > time you install changes), and was already taken care of for your > case. I see, thank you. -- Sean Whitton ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-04-08 14:06 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <164921225790.11115.15669298143254852205@vcs2.savannah.gnu.org> [not found] ` <20220406023058.315C7C009A8@vcs2.savannah.gnu.org> 2022-04-06 15:37 ` master f0ff20be51: * src/emacs.c (main): Improve accuracy of daemon warning message on PGTK Sean Whitton 2022-04-06 15:44 ` Robert Pluim 2022-04-06 18:45 ` Sean Whitton 2022-04-06 20:12 ` Óscar Fuentes 2022-04-07 0:32 ` Po Lu 2022-04-07 0:28 ` Po Lu 2022-04-07 0:49 ` Sean Whitton 2022-04-07 1:02 ` Po Lu 2022-04-07 2:11 ` Stefan Monnier 2022-04-07 2:45 ` Po Lu 2022-04-07 3:16 ` Stefan Monnier 2022-04-07 5:32 ` Sean Whitton 2022-04-07 23:04 ` Stefan Monnier 2022-04-08 4:09 ` Sean Whitton 2022-04-08 5:29 ` Sean Whitton 2022-04-08 6:13 ` Eli Zaretskii 2022-04-08 14:06 ` Sean Whitton
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).