bug#63555: emacs 29 complains that it can't connect to the display

bug#63555: emacs 29 complains that it can't connect to the display

[Phillip Susi]

Package: emacs
Version: 29.0.90

In previous versions of emacs, if the DISPLAY/WAYLAND_DISPLAY variable
was not set, it would default to tty mode.  In version 29, it seems to
assume a default value and complains that it can't connect to the
display server unless you run it with -nw.

bug#63555: emacs 29 complains that it can't connect to the display

[Phillip Susi]

Here is my build configuration:

In GNU Emacs 29.0.90 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.37, cairo version 1.17.8) of 2023-05-16 built on localhost
System Description: Gentoo Linux

Configured using:
 'configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --datarootdir=/usr/share
 --disable-silent-rules --docdir=/usr/share/doc/emacs-29.0.90
 --htmldir=/usr/share/doc/emacs-29.0.90/html --libdir=/usr/lib64
 --program-suffix=-emacs-29-vcs --includedir=/usr/include/emacs-29-vcs
 --infodir=/usr/share/info/emacs-29-vcs --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --without-compress-install --without-hesiod --without-pop
 --with-file-notification=inotify --with-pdumper --enable-acl
 --with-dbus --with-modules --without-gameuser --with-libgmp --with-gpm
 --with-native-compilation=aot --without-json --without-kerberos
 --without-kerberos5 --with-lcms2 --without-xml2 --without-mailutils
 --without-selinux --without-sqlite3 --with-gnutls --with-libsystemd
 --with-threads --with-tree-sitter --without-wide-int --with-sound=alsa
 --with-zlib --with-pgtk --without-x --without-ns
 --with-toolkit-scroll-bars --without-gconf --without-gsettings
 --without-harfbuzz --without-libotf --without-m17n-flt
 --without-xwidgets --with-gif --with-jpeg --with-png --with-rsvg
 --with-tiff --without-webp --without-imagemagick --with-dumping=pdumper
 'CFLAGS=-march=native -O2 -pipe' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM JPEG LCMS2 LIBSYSTEMD
MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER XIM GTK3 ZLIB

Important settings:
  value of $LANG: C.UTF8
  locale-coding-system: utf-8-unix

bug#63555: emacs 29 complains that it can't connect to the display

[Eli Zaretskii]

> From: Phillip Susi <phill@thesusis.net>
> Date: Wed, 17 May 2023 09:51:43 -0400
> 
> Package: emacs
> Version: 29.0.90
> 
> In previous versions of emacs, if the DISPLAY/WAYLAND_DISPLAY variable
> was not set, it would default to tty mode.  In version 29, it seems to
> assume a default value and complains that it can't connect to the
> display server unless you run it with -nw.

Po Lu, was this an intentional change?  If so, did we document the
reasons?  I cannot find anything in NEWS.

Thanks.

bug#63555: emacs 29 complains that it can't connect to the display

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Phillip Susi <phill@thesusis.net>
>> Date: Wed, 17 May 2023 09:51:43 -0400
>> 
>> Package: emacs
>> Version: 29.0.90
>> 
>> In previous versions of emacs, if the DISPLAY/WAYLAND_DISPLAY variable
>> was not set, it would default to tty mode.  In version 29, it seems to
>> assume a default value and complains that it can't connect to the
>> display server unless you run it with -nw.
>
> Po Lu, was this an intentional change?  If so, did we document the
> reasons?  I cannot find anything in NEWS.

No, I don't think so.  This isn't intentional.
Phillip, please place a breakpoint on `init_display_interactive' in
src/dispnew.c.  Then, step to this piece of code:

  if (! inhibit_window_system && ! display_arg)
    {
      char *display;
      display = getenv ("DISPLAY");
      display_arg = (display != 0 && *display != 0); <----------

      if (display_arg && !x_display_ok (display))
	{
	  fprintf (stderr, "Display %s unavailable, simulating -nw\n",
		   display);
	  inhibit_window_system = 1;
	}
    }

and show:

  (gdb) p display

Thanks.

bug#63555: emacs 29 complains that it can't connect to the display

[Robert Pluim]

>>>>> On Fri, 19 May 2023 15:22:22 +0800, Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:

    Po Lu> Eli Zaretskii <eliz@gnu.org> writes:
    >>> From: Phillip Susi <phill@thesusis.net>
    >>> Date: Wed, 17 May 2023 09:51:43 -0400
    >>> 
    >>> Package: emacs
    >>> Version: 29.0.90
    >>> 
    >>> In previous versions of emacs, if the DISPLAY/WAYLAND_DISPLAY variable
    >>> was not set, it would default to tty mode.  In version 29, it seems to
    >>> assume a default value and complains that it can't connect to the
    >>> display server unless you run it with -nw.
    >> 
    >> Po Lu, was this an intentional change?  If so, did we document the
    >> reasons?  I cannot find anything in NEWS.

    Po Lu> No, I don't think so.  This isn't intentional.
    Po Lu> Phillip, please place a breakpoint on `init_display_interactive' in
    Po Lu> src/dispnew.c.  Then, step to this piece of code:

    Po Lu>   if (! inhibit_window_system && ! display_arg)
    Po Lu>     {
    Po Lu>       char *display;
    Po Lu>       display = getenv ("DISPLAY");
    Po Lu>       display_arg = (display != 0 && *display != 0); <----------

    Po Lu>       if (display_arg && !x_display_ok (display))
    Po Lu> 	{
    Po Lu> 	  fprintf (stderr, "Display %s unavailable, simulating -nw\n",
    Po Lu> 		   display);
    Po Lu> 	  inhibit_window_system = 1;
    Po Lu> 	}
    Po Lu>     }

    Po Lu> and show:

    Po Lu>   (gdb) p display

HAVE_X_WINDOWS is not defined in a pgtk build, so this code is never
run. And it looks kind of X-specific in any case

Robert
-- 

bug#63555: emacs 29 complains that it can't connect to the display

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Phillip Susi <phill@thesusis.net>,
>  63555@debbugs.gnu.org
> Date: Fri, 19 May 2023 15:26:42 +0200
> 
>     >> Po Lu, was this an intentional change?  If so, did we document the
>     >> reasons?  I cannot find anything in NEWS.
> 
>     Po Lu> No, I don't think so.  This isn't intentional.
>     Po Lu> Phillip, please place a breakpoint on `init_display_interactive' in
>     Po Lu> src/dispnew.c.  Then, step to this piece of code:
> 
>     Po Lu>   if (! inhibit_window_system && ! display_arg)
>     Po Lu>     {
>     Po Lu>       char *display;
>     Po Lu>       display = getenv ("DISPLAY");
>     Po Lu>       display_arg = (display != 0 && *display != 0); <----------
> 
>     Po Lu>       if (display_arg && !x_display_ok (display))
>     Po Lu> 	{
>     Po Lu> 	  fprintf (stderr, "Display %s unavailable, simulating -nw\n",
>     Po Lu> 		   display);
>     Po Lu> 	  inhibit_window_system = 1;
>     Po Lu> 	}
>     Po Lu>     }
> 
>     Po Lu> and show:
> 
>     Po Lu>   (gdb) p display
> 
> HAVE_X_WINDOWS is not defined in a pgtk build, so this code is never
> run. And it looks kind of X-specific in any case

How did this work in Emacs 28, then?  IOW, which change broke this
feature on Wayland?

bug#63555: emacs 29 complains that it can't connect to the display

[Robert Pluim]

>>>>> On Fri, 19 May 2023 17:52:06 +0300, Eli Zaretskii <eliz@gnu.org> said:
    >> HAVE_X_WINDOWS is not defined in a pgtk build, so this code is never
    >> run. And it looks kind of X-specific in any case

    Eli> How did this work in Emacs 28, then?  IOW, which change broke this
    Eli> feature on Wayland?

Emacs 28 didnʼt have pgtk, so GTK <=> XWindows, even when running
under (X)Wayland.

Robert
-- 

bug#63555: emacs 29 complains that it can't connect to the display

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

Robert Pluim <rpluim@gmail.com> writes:

> HAVE_X_WINDOWS is not defined in a pgtk build, so this code is never
> run. And it looks kind of X-specific in any case

Phillip is using a PGTK build?  I must've missed that, sorry.

bug#63555: emacs 29 complains that it can't connect to the display

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

Eli Zaretskii <eliz@gnu.org> writes:

> How did this work in Emacs 28, then?  IOW, which change broke this
> feature on Wayland?

Emacs 28 didn't have a PGTK build at all.

The trick in dispnew.c doesn't work on a PGTK build, because Emacs
doesn't know every one of the environment variables GDK backends look at
when trying to find a default display.  So if Phillip is indeed using a
PGTK build, there is no bug here.

bug#63555: emacs 29 complains that it can't connect to the display

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Robert Pluim <rpluim@gmail.com>,  phill@thesusis.net,
>   63555@debbugs.gnu.org
> Date: Sat, 20 May 2023 09:40:04 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How did this work in Emacs 28, then?  IOW, which change broke this
> > feature on Wayland?
> 
> Emacs 28 didn't have a PGTK build at all.
> 
> The trick in dispnew.c doesn't work on a PGTK build, because Emacs
> doesn't know every one of the environment variables GDK backends look at
> when trying to find a default display.  So if Phillip is indeed using a
> PGTK build, there is no bug here.

Why cannot we "simulate -nw" where we issue the error message that we
cannot connect to the display server?  At that point, we presumably
already know that the default display could not be found.

bug#63555: emacs 29 complains that it can't connect to the display

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

Eli Zaretskii <eliz@gnu.org> writes:

> Why cannot we "simulate -nw" where we issue the error message that we
> cannot connect to the display server?  At that point, we presumably
> already know that the default display could not be found.

That happens very late in the initialization process, in
`normal-top-level'.

bug#63555: emacs 29 complains that it can't connect to the display

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  phill@thesusis.net,  63555@debbugs.gnu.org
> Date: Sat, 20 May 2023 14:33:09 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Why cannot we "simulate -nw" where we issue the error message that we
> > cannot connect to the display server?  At that point, we presumably
> > already know that the default display could not be found.
> 
> That happens very late in the initialization process, in
> `normal-top-level'.

What function(s) is/are used at that point which tells us a GUI
session is impossible?  Can we invoke those same functions earlier
during startup to realize this fact where we still can start as -nw?

bug#63555: emacs 29 complains that it can't connect to the display

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

Eli Zaretskii <eliz@gnu.org> writes:

> What function(s) is/are used at that point which tells us a GUI
> session is impossible?

window-system-initialization.

> Can we invoke those same functions earlier during startup to realize
> this fact where we still can start as -nw?

Unfortunately not.  At least, not enough to make a change suitable for
the release branch.

bug#63555: emacs 29 complains that it can't connect to the display

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  phill@thesusis.net,  63555@debbugs.gnu.org
> Date: Sat, 20 May 2023 16:28:30 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What function(s) is/are used at that point which tells us a GUI
> > session is impossible?
> 
> window-system-initialization.
> 
> > Can we invoke those same functions earlier during startup to realize
> > this fact where we still can start as -nw?
> 
> Unfortunately not.  At least, not enough to make a change suitable for
> the release branch.

Too bad.  I added some verbiage to this effect in NEWS, and I'm
closing this bug.

(With all these disadvantages, I wonder why the PGTK build was
considered such a useful addition to Emacs...)

Btw, the Emacs user manual says WAYLAND_DISPLAY is the variable used
by PGTK, which you seem to say is inaccurate?

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Phillip Susi]

Eli Zaretskii <eliz@gnu.org> writes:

> > Can we invoke those same functions earlier during startup to realize
> > this fact where we still can start as -nw?
> 
> Unfortunately not.  At least, not enough to make a change suitable for
> the release branch.

Why not?  How hard can it be to set -nw if neither DISPLAY nor
WAYLAND_DISPLAY is set, as emacs always has, prior to
window-system-initialization?

> Btw, the Emacs user manual says WAYLAND_DISPLAY is the variable used
> by PGTK, which you seem to say is inaccurate?

Yes, WAYLAND_DISPLAY is used if it is set ( as it will be under wayland
), or DISPLAY otherwise ( under X11, or wayland with Xwayland ).

bug#63555: emacs 29 complains that it can't connect to the display

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

Eli Zaretskii <eliz@gnu.org> writes:

> Too bad.  I added some verbiage to this effect in NEWS, and I'm
> closing this bug.
>
> (With all these disadvantages, I wonder why the PGTK build was
> considered such a useful addition to Emacs...)

To be fair, it solves the problem of running Emacs under Wayland
reasonably well.

> Btw, the Emacs user manual says WAYLAND_DISPLAY is the variable used
> by PGTK, which you seem to say is inaccurate?

WAYLAND_DISPLAY is one of the variables, but there are others too,
depending on which GDK backends are in use (Broadway, Cygwin, Quartz,
etc.)  There may also be new GDK backends in the future.

The user manual should be fixed.

bug#63555: emacs 29 complains that it can't connect to the display

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  phill@thesusis.net,  63555-done@debbugs.gnu.org
> Date: Sun, 21 May 2023 08:45:06 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Too bad.  I added some verbiage to this effect in NEWS, and I'm
> > closing this bug.
> >
> > (With all these disadvantages, I wonder why the PGTK build was
> > considered such a useful addition to Emacs...)
> 
> To be fair, it solves the problem of running Emacs under Wayland
> reasonably well.

For some value of "reasonably well".  It's the only configuration for
which we explicitly warn users that very bad things could happen
unless they do so-and-so.

> > Btw, the Emacs user manual says WAYLAND_DISPLAY is the variable used
> > by PGTK, which you seem to say is inaccurate?
> 
> WAYLAND_DISPLAY is one of the variables, but there are others too,
> depending on which GDK backends are in use (Broadway, Cygwin, Quartz,
> etc.)  There may also be new GDK backends in the future.
> 
> The user manual should be fixed.

Please do this ASAP.  Or tell me what should be written there, and
then I will do it.

bug#63555: emacs 29 complains that it can't connect to the display

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

Eli Zaretskii <eliz@gnu.org> writes:

> Please do this ASAP.  Or tell me what should be written there, and
> then I will do it.

How about this:

diff --git a/doc/emacs/cmdargs.texi b/doc/emacs/cmdargs.texi
index 9514e3414e1..0abd1ec589c 100644
--- a/doc/emacs/cmdargs.texi
+++ b/doc/emacs/cmdargs.texi
@@ -777,8 +777,13 @@ Misc Variables
 time it is required.
 
 @item WAYLAND_DISPLAY
-Pgtk Emacs (built with @option{--with-pgtk}) can run on Wayland natively.
-@env{WAYLAND_DISPLAY} specifies the connection to the compositor.
+@item BROADWAY_DISPLAY
+When Emacs is built with the @option{--with-pgtk}, it can natively run
+on Wayland, if GTK was built with its Wayland backend enabled.
+@env{WAYLAND_DISPLAY} specifies the name of the Wayland display.
+
+Other backends may use other environment variables to specify the
+display name: Broadway, for example, uses @env{BROADWAY_DISPLAY}.
 
 @item emacs_dir
 On MS-Windows, @env{emacs_dir} is a special environment variable, which

bug#63555: emacs 29 complains that it can't connect to the display

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: rpluim@gmail.com,  phill@thesusis.net,  63555@debbugs.gnu.org
> Date: Sun, 21 May 2023 14:32:46 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please do this ASAP.  Or tell me what should be written there, and
> > then I will do it.
> 
> How about this:
> 
> diff --git a/doc/emacs/cmdargs.texi b/doc/emacs/cmdargs.texi
> index 9514e3414e1..0abd1ec589c 100644
> --- a/doc/emacs/cmdargs.texi
> +++ b/doc/emacs/cmdargs.texi
> @@ -777,8 +777,13 @@ Misc Variables
>  time it is required.
>  
>  @item WAYLAND_DISPLAY
> -Pgtk Emacs (built with @option{--with-pgtk}) can run on Wayland natively.
> -@env{WAYLAND_DISPLAY} specifies the connection to the compositor.
> +@item BROADWAY_DISPLAY
   ^^^^^
"@itemx"

> +When Emacs is built with the @option{--with-pgtk}, it can natively run
                            ^^^
This "the" should be deleted.

> +on Wayland, if GTK was built with its Wayland backend enabled.
> +@env{WAYLAND_DISPLAY} specifies the name of the Wayland display.
> +
> +Other backends may use other environment variables to specify the
> +display name: Broadway, for example, uses @env{BROADWAY_DISPLAY}.

Can we document other variables as well?

Also, I don't think I understand: is Broadway one of the backends for
Wayland?  And Wayland is another backend?  The text says "can run on
Wayland", but then uses "Wayland" as the name of one backend of many.
So it's a bit confusing: is "Wayland" the name of a backend, the
generic name of the GTK backends, or something else?

Thanks.

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Robert Pluim]

>>>>> On Sat, 20 May 2023 13:35:56 -0400, Phillip Susi <phill@thesusis.net> said:

    Phillip> Eli Zaretskii <eliz@gnu.org> writes:

    >> > Can we invoke those same functions earlier during startup to realize
    >> > this fact where we still can start as -nw?
    >> 
    >> Unfortunately not.  At least, not enough to make a change suitable for
    >> the release branch.

    Phillip> Why not?  How hard can it be to set -nw if neither DISPLAY nor
    Phillip> WAYLAND_DISPLAY is set, as emacs always has, prior to
    Phillip> window-system-initialization?

Not too hard. Very much for master, though (and Iʼd need to check if
gtk_init_check has any GTK version dependencies).

diff --git a/src/dispnew.c b/src/dispnew.c
index a928a5d1b14..9a23fb5a182 100644
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -6518,7 +6518,28 @@ init_display_interactive (void)
      try to use X, and if that fails output a line to stderr
      reporting that -nw will be simulated.  */
 
-#ifdef HAVE_X_WINDOWS
+#ifdef HAVE_PGTK
+  if (! inhibit_window_system)
+    {
+     if (! gtk_init_check (0, 0))
+	{
+	  fprintf (stderr, "PGTK display unavailable, simulating -nw\nCheck your $DISPLAY, $WAYLAND_DISPLAY, or $BROADWAY_DISPLAY\n");
+	  inhibit_window_system = 1;
+	}
+    }
+
+  if (!inhibit_window_system)
+    {
+      Vinitial_window_system = Qpgtk;
+#ifdef USE_NCURSES
+      /* In some versions of ncurses,
+	 tputs crashes if we have not called tgetent.
+	 So call tgetent.  */
+      { char b[2044]; tgetent (b, "xterm");}
+#endif
+      return;
+    }
+#elif defined (HAVE_X_WINDOWS)
   if (! inhibit_window_system && ! display_arg)
     {
       char *display;


Robert
-- 

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

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

Robert Pluim <rpluim@gmail.com> writes:

> Not too hard. Very much for master, though (and Iʼd need to check if
> gtk_init_check has any GTK version dependencies).
>
> diff --git a/src/dispnew.c b/src/dispnew.c
> index a928a5d1b14..9a23fb5a182 100644
> --- a/src/dispnew.c
> +++ b/src/dispnew.c
> @@ -6518,7 +6518,28 @@ init_display_interactive (void)
>       try to use X, and if that fails output a line to stderr
>       reporting that -nw will be simulated.  */
>  
> -#ifdef HAVE_X_WINDOWS
> +#ifdef HAVE_PGTK
> +  if (! inhibit_window_system)
> +    {
> +     if (! gtk_init_check (0, 0))
> +	{
> +	  fprintf (stderr, "PGTK display unavailable, simulating -nw\nCheck your $DISPLAY, $WAYLAND_DISPLAY, or $BROADWAY_DISPLAY\n");
> +	  inhibit_window_system = 1;
> +	}
> +    }

The problem with this approach is that gtk_init_check initializes the
window system upon success, so once pgtk_term_init is called in
pgtkterm.c, the window system is set up a second time, leaving two
display connections open...

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Robert Pluim]

>>>>> On Mon, 22 May 2023 17:26:27 +0800, Po Lu <luangruo@yahoo.com> said:

    Po> The problem with this approach is that gtk_init_check initializes the
    Po> window system upon success, so once pgtk_term_init is called in
    Po> pgtkterm.c, the window system is set up a second time, leaving two
    Po> display connections open...

Is there anything stopping us from removing that call to gtk_init?

Robert
-- 

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

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

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Mon, 22 May 2023 17:26:27 +0800, Po Lu <luangruo@yahoo.com> said:
>
>     Po> The problem with this approach is that gtk_init_check initializes the
>     Po> window system upon success, so once pgtk_term_init is called in
>     Po> pgtkterm.c, the window system is set up a second time, leaving two
>     Po> display connections open...
>
> Is there anything stopping us from removing that call to gtk_init?

Yes, since the PGTK build is supposed to support multiple displays.

BTW, the other problem with calling `gtk_init_check' is that when it
returns FALSE, calling any other GTK function results in undefined
behavior.  Thus, if `gtk_init_check' is used at startup, opening a
display later becomes unsafe, even if a display connection is then
available.

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Robert Pluim]

>>>>> On Mon, 22 May 2023 19:15:40 +0800, Po Lu <luangruo@yahoo.com> said:

    Po Lu> Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Mon, 22 May 2023 17:26:27 +0800, Po Lu <luangruo@yahoo.com> said:
    >> 
    Po> The problem with this approach is that gtk_init_check initializes the
    Po> window system upon success, so once pgtk_term_init is called in
    Po> pgtkterm.c, the window system is set up a second time, leaving two
    Po> display connections open...
    >> 
    >> Is there anything stopping us from removing that call to gtk_init?

    Po Lu> Yes, since the PGTK build is supposed to support multiple displays.

Ha! And has anyone actually tested that? :-)

    Po Lu> BTW, the other problem with calling `gtk_init_check' is that when it
    Po Lu> returns FALSE, calling any other GTK function results in undefined
    Po Lu> behavior.  Thus, if `gtk_init_check' is used at startup, opening a
    Po Lu> display later becomes unsafe, even if a display connection is then
    Po Lu> available.

Do the gtk folks deliberately set out to make their usersʼ lives
difficult, or is it accidental?

Looks like Eliʼs NEWS entry is it, then.

Robert
-- 

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

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

Robert Pluim <rpluim@gmail.com> writes:

> Ha! And has anyone actually tested that? :-)

I did.  It works, but as expected, loses if a display connection is then
closed by any means other than being destroyed immediately after being
set up.

> Do the gtk folks deliberately set out to make their usersʼ lives
> difficult, or is it accidental?

I have no idea.

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Phillip Susi]

Po Lu <luangruo@yahoo.com> writes:

>> Is there anything stopping us from removing that call to gtk_init?
>
> Yes, since the PGTK build is supposed to support multiple displays.

What does multiple displays have to do with it?  If gtk_init_check()
tries to connect to the display sever, then itsn't it that call that
should be skipped if none of those 3 environment variables are set?

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Phillip Susi]

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


This patch works for me.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: auto-nw-mode.patch --]
[-- Type: text/x-diff, Size: 713 bytes --]

Index: b/src/dispnew.c
===================================================================
--- a/src/dispnew.c
+++ b/src/dispnew.c
@@ -6559,8 +6558,20 @@ init_display_interactive (void)
 #ifdef HAVE_PGTK
   if (!inhibit_window_system && !will_dump_p ())
     {
-      Vinitial_window_system = Qpgtk;
-      return;
+      char *display, *wayland_display;
+      display = getenv ("DISPLAY");
+      wayland_display = getenv ("WAYLAND_DISPLAY");
+
+      if (display == NULL && wayland_display == NULL)
+	{
+	  fprintf (stderr, "Neither DISPLAY nor WAYLAND_DISPLAY are set, simulating -nw\n");
+	  inhibit_window_system = 1;
+	}
+      else
+	{
+	  Vinitial_window_system = Qpgtk;
+	  return;
+	}
     }
 #endif
 

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Robert Pluim]

>>>>> On Mon, 22 May 2023 12:44:40 -0400, Phillip Susi <phill@thesusis.net> said:

    Phillip> This patch works for me.

    Phillip> Index: b/src/dispnew.c
    Phillip> ===================================================================
    Phillip> --- a/src/dispnew.c
    Phillip> +++ b/src/dispnew.c
    Phillip> @@ -6559,8 +6558,20 @@ init_display_interactive (void)
    Phillip>  #ifdef HAVE_PGTK
    Phillip>    if (!inhibit_window_system && !will_dump_p ())
    Phillip>      {
    Phillip> -      Vinitial_window_system = Qpgtk;
    Phillip> -      return;
    Phillip> +      char *display, *wayland_display;
    Phillip> +      display = getenv ("DISPLAY");
    Phillip> +      wayland_display = getenv ("WAYLAND_DISPLAY");
    Phillip> +
    Phillip> +      if (display == NULL && wayland_display == NULL)
    Phillip> +	{
    Phillip> +	  fprintf (stderr, "Neither DISPLAY nor WAYLAND_DISPLAY are set, simulating -nw\n");
    Phillip> +	  inhibit_window_system = 1;
    Phillip> +	}
    Phillip> +      else
    Phillip> +	{
    Phillip> +	  Vinitial_window_system = Qpgtk;
    Phillip> +	  return;
    Phillip> +	}
    Phillip>      }
    Phillip>  #endif
 
I think you need to check for them being non-empty as well

Robert
-- 

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

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

Phillip Susi <phill@thesusis.net> writes:

> What does multiple displays have to do with it?  If gtk_init_check()
> tries to connect to the display sever, then itsn't it that call that
> should be skipped if none of those 3 environment variables are set?

Future GDK backends might use different environment variables -- or none
at all.

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Phillip Susi]

Robert Pluim <rpluim@gmail.com> writes:

> I think you need to check for them being non-empty as well

Good point.

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Phillip Susi]

Po Lu <luangruo@yahoo.com> writes:

> Future GDK backends might use different environment variables -- or none
> at all.

So?  Worry about the potential future when it comes.

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

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

Phillip Susi <phill@thesusis.net> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Future GDK backends might use different environment variables -- or none
>> at all.
>
> So?  Worry about the potential future when it comes.

The PGTK code aims to work with all possible GDK configurations which
are not positively broken (which means, not the X11 backend.)

Anyway, see what I said about `gtk_init_check': it doesn't work.

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Phillip Susi]

Po Lu <luangruo@yahoo.com> writes:

> The PGTK code aims to work with all possible GDK configurations which
> are not positively broken (which means, not the X11 backend.)
>
> Anyway, see what I said about `gtk_init_check': it doesn't work.

That's why I suggested just checking the enironment instead, like is
done for the X11 build.

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

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

Phillip Susi <phill@thesusis.net> writes:

> That's why I suggested just checking the enironment instead, like is
> done for the X11 build.

Xlib uses only ``DISPLAY'', and that is documented.  The environment
variables used by GDK are not, and are subject to change.

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Robert Pluim]

>>>>> On Fri, 26 May 2023 09:00:57 +0800, Po Lu <luangruo@yahoo.com> said:

    Po Lu> Phillip Susi <phill@thesusis.net> writes:
    >> That's why I suggested just checking the enironment instead, like is
    >> done for the X11 build.

    Po Lu> Xlib uses only ``DISPLAY'', and that is documented.  The environment
    Po Lu> variables used by GDK are not, and are subject to change.

I see no reason to let the perfect be the enemy of the good. If we
later have to amend the list thatʼs not a big issue.

Robert
-- 

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Phillip Susi]

Robert Pluim <rpluim@gmail.com> writes:

> I see no reason to let the perfect be the enemy of the good. If we
> later have to amend the list thatʼs not a big issue.

Exactly.

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

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

Phillip Susi <phill@thesusis.net> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> I see no reason to let the perfect be the enemy of the good. If we
>> later have to amend the list thatʼs not a big issue.
>
> Exactly.

And what about the GDK backends which use no environment variable at
all?  For example, Cygwin w32, Quartz, and simplefb?

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Phillip Susi]

Po Lu <luangruo@yahoo.com> writes:

> And what about the GDK backends which use no environment variable at
> all?  For example, Cygwin w32, Quartz, and simplefb?

Hrm... maybe something in .emacs could be used to disable the check?
Or maybe it could be disabled by default and have a setting to enable
it?

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

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

Phillip Susi <phill@thesusis.net> writes:

> Hrm... maybe something in .emacs could be used to disable the check?
> Or maybe it could be disabled by default and have a setting to enable
> it?

The point is, this is overengineering for a check that 99% of people are
not going to need.  We have no such checks on the NS port or the MS
Windows, and it is at least possible to log in to a Mac OS system from a
terminal with no display connection.

bug#63555: closed (Re: bug#63555: emacs 29 complains that it can't connect to the display)

[Daan Ro]

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

> I think you need to check for them being non-empty as well

Good point.
If you have done that, may you share the patch?

Daanturo


[-- Attachment #2: Type: text/html, Size: 845 bytes --]