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

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

[Trent W. Buck]

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.

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.
But "emacsclient --create-frame" won't work until/unless it checks $BROADWAY_DISPLAY, right?

And while emacs daemon can tell from just
"-display ${WAYLAND_DISPLAY:-$DISPLAY}"
when wayland is wanted (because WAYLAND_DISPLAY starts with "wayland-"),
that's *not* possible with broadway.
So some kind of additional logic is needed on the server side, too?
Or maybe -display :0 will Just Work as long as emacs --daemon also has GDK_BACKEND=broadway?
I don't fully understand what happens inside the GTK layer.

My main use case for this is to have a GUI when running Emacs in Debian GNU/ntoskrnl (a.k.a. WSL1).
That way I have full, completely normal GNU userland (unlike NTEmacs), but
Indic scripts render properly (unlike Debian GNU emacs -nw inside Microsoft Terminal).
(The normal ways to solve this are WSL2 or MSYS2, but I like being weird.)

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.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

"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?

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

[Trent W. Buck]

[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]

On Wed 02 Aug 2023 21:06:09 +0800, Po Lu wrote:
> > But "emacsclient --create-frame" won't work until/unless it checks
> > $BROADWAY_DISPLAY, right?
> 
> Correct.

I did some testing.
It appears to Just Work for basic usage (single display server).

I put some screenshots here: https://imgur.com/a/RSfScXt
I've also attached a single before/after pair.

One thing that really surprised me: quitting emacs (e.g. via M-x kill-emacs) causes broadwayd to crash!
This is not the case for gtk3-demo, so it might be a weirdness in emacs.

I also tested if GTK3 apps can display in gtk4-broadwayd, and
if GTK4 apps can display in [gtk3]-broadwayd.  It seems they cannot.

> > 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.

I think your argument is reasonable and sensible.

> 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?

For my personal use I think Emacs's current behaviour is adequate.
(i.e. I think this bug ticket can be closed.)


The Debian people seem to be OK with shipping a per-build emacsclient
(i.e. emacsclient moves from "emacs-bin-common" to "emacs-<variant>" deb).
That means the existing "#ifdef pgtk then check $WAYLAND_DISPLAY" will be OK.
At least for most users, most of the time.


I'm really excited that I finally have pgtk through my normal distro channels! It's cool! :-)

[-- Attachment #2: imgur_RSfScXt_008_NQ1Ahki.png --]
[-- Type: image/png, Size: 102503 bytes --]

[-- Attachment #3: imgur_RSfScXt_009_Fnd3KWp.png --]
[-- Type: image/png, Size: 263273 bytes --]