Re: long-standing GTK bug

[Adam Sjøgren]

You may recall that around 92 weeks ago I wrote:

> However, my quick test required me to copy the struct _GMainContext
> definition from glib/gmain.c into xterm.c, which is not the correct way
> to go about this, I'm sure.
>
> I do feel that this is progress, though. Now we just need to figure out
> the right way to handle it.
>
> If that is for gdk_display_close() to reset the in_check_or_prepare
> counter, or if it is something that can be changed in Emacs, I don't
> know.
>
> I have updated the current GTK issue⁴ with my observations, but I'm
> hoping for some input from emacs-devel as well.

A recent blog post:
https://tychoish.com/post/the-emacs-daemon-gtk-bug-a-parable/ made me
aware of the continued discussion that happened on the GTK issue 11
months ago, which I had previously missed.

A very interesting comment is this one by Michel Dänzer:

    FWIW, the upcoming release 40 of mutter (which uses GTK3 for drawing
    X11 client window decorations) is able to survive Xwayland dying
    abruptly, using the new XSetIOErrorExitHandler API (which removes
    the need for longjmp hacks) available as of libX11 1.7.0.

     · https://gitlab.gnome.org/GNOME/gtk/-/issues/2315#note_1052481

Which sounds like exactly what is needed, doesn't it?

Switch from using the current XIOErrorHandler to the "new"
XSetIOErrorExitHandler API to avoid the longjmp and the sketchy patchy
hackery I ended up with.

This API is available in libX11 1.7.0 - I just checked the version in
Debian stable, and it is 1.7.2, so it's not some outrageously new
bleeding edge addition.

Now we just need someone with libX11 API chops to start ... eh,
chopping!


  11 years down the line, feeling optimistic,

    Adam

-- 
 "Jeg er som en pære når jeg springer og mister min         Adam Sjøgren
  fatning!"                                            asjo@koldfront.dk