bug#65009: 29.1; should emacsclient check BROADWAY_DISPLAY as well as WAYLAND_DISPLAY and DISPLAY?

[Po Lu]

"Trent W. Buck" <trentbuck@gmail.com> writes:

> I'm writing this from Emacs 28.2 still, but this is about pgtk 29.1.
> I haven't actually tested pgtk myself yet (sorry!)
>
> The good folks of #debian-emacs noticed that while emacsclient doesn't
> link to any GUI libraries, it does check GUI environment variables.
>
>     
> https://sources.debian.org/src/emacs/1:29.1+1-2/lib-src/emacsclient.c/?hl=1703#L631-L636
>
>     631  #ifdef HAVE_PGTK
>     632        display = egetenv ("WAYLAND_DISPLAY");
>     633        alt_display = egetenv ("DISPLAY");
>     634  #else
>     635        display = egetenv ("DISPLAY");
>     636  #endif
>
> This (maybe) causes weirdness when Debian builds several versions of
> /bin/emacs, but a single shared version of /bin/emacsclient.

Debian should packge Emacsclient within their Emacs packages themselves,
since its behavior differs between different configurations.  If that's
not practical, Debian should at least strive to install Emacsclient for
each installed Emacs configuration under a unique name.

> But THIS bug is about what happens if you're running emacs inside the
> browser, using GTK's built-in HTML5 backend:
>
>     # Start the display (a.k.a. web server)
>     broadwayd :0 &
>
>     # Connect from a client (could be a different container)
>     firefox http://127.0.0.1:8080
>
>     # start some GUI apps
>     GDK_BACKEND=broadway BROADWAY_DISPLAY=:0 gtk3-demo &
>     GDK_BACKEND=broadway BROADWAY_DISPLAY=:0 gnome-terminal -- emacs -nw &
>     GDK_BACKEND=broadway BROADWAY_DISPLAY=:0 virt-manager &
>     GDK_BACKEND=broadway BROADWAY_DISPLAY=:0 emacs &
>
> AIUI pGTK makes Emacs a fully native GTK app and this Just Works.

Yes.  BTW, the `P' in ``PGTK'' should be capitalized.

> But "emacsclient --create-frame" won't work until/unless it checks
> $BROADWAY_DISPLAY, right?

Correct.

> If the general consensus is "too hard; WONTFIX", I am OK with that.
> This is something I want a couple of times a year, not every single
> day.

If such a fix only serves the interests of a few users of WSL, then yes.
But we still receive occasional reports of frustration with
Emacsclient's display detection from Wayland users on GNU/Linux, so this
problem will have to be tackled.

However, I'm not willing to settle for replicating GDK's own display
selection mechanism using the names of a few environment variables that
simply coincide with those used by common GDK configurations.  Going
down that route would be incredibly fragile, and make Emacs even more
subject to GDK's petty whims.

Perhaps, for the time being, PGTK builds should forgo checking for a
display in Emacsclient, and simply use whatever display connection was
last opened.

Comments?