GNU bug report logs -
#63555
emacs 29 complains that it can't connect to the display
Previous Next
Reported by: Phillip Susi <phill <at> thesusis.net>
Date: Wed, 17 May 2023 13:55:03 UTC
Severity: normal
Found in version 29.0.90
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63555 in the body.
You can then email your comments to 63555 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Wed, 17 May 2023 13:55:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Phillip Susi <phill <at> thesusis.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 17 May 2023 13:55:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Wed, 17 May 2023 14:14:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 63555 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Fri, 19 May 2023 06:12:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 63555 <at> debbugs.gnu.org (full text, mbox):
> From: Phillip Susi <phill <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Fri, 19 May 2023 07:23:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Phillip Susi <phill <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Fri, 19 May 2023 13:27:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 63555 <at> debbugs.gnu.org (full text, mbox):
>>>>> 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 <at> gnu.org> said:
Po Lu> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> From: Phillip Susi <phill <at> 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
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Fri, 19 May 2023 14:53:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 63555 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Phillip Susi <phill <at> thesusis.net>,
> 63555 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Fri, 19 May 2023 15:45:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 63555 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 19 May 2023 17:52:06 +0300, Eli Zaretskii <eliz <at> 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
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sat, 20 May 2023 01:39:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sat, 20 May 2023 01:41:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sat, 20 May 2023 05:52:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 63555 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Robert Pluim <rpluim <at> gmail.com>, phill <at> thesusis.net,
> 63555 <at> debbugs.gnu.org
> Date: Sat, 20 May 2023 09:40:04 +0800
>
> Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sat, 20 May 2023 06:34:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sat, 20 May 2023 08:17:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 63555 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: rpluim <at> gmail.com, phill <at> thesusis.net, 63555 <at> debbugs.gnu.org
> Date: Sat, 20 May 2023 14:33:09 +0800
>
> Eli Zaretskii <eliz <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sat, 20 May 2023 08:29:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 20 May 2023 12:59:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Phillip Susi <phill <at> thesusis.net>:
bug acknowledged by developer.
(Sat, 20 May 2023 12:59:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 63555-done <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: rpluim <at> gmail.com, phill <at> thesusis.net, 63555 <at> debbugs.gnu.org
> Date: Sat, 20 May 2023 16:28:30 +0800
>
> Eli Zaretskii <eliz <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sat, 20 May 2023 17:42:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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 ).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sun, 21 May 2023 00:46:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 63555-done <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sun, 21 May 2023 05:41:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 63555 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: rpluim <at> gmail.com, phill <at> thesusis.net, 63555-done <at> debbugs.gnu.org
> Date: Sun, 21 May 2023 08:45:06 +0800
>
> Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sun, 21 May 2023 06:34:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sun, 21 May 2023 11:17:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 63555 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: rpluim <at> gmail.com, phill <at> thesusis.net, 63555 <at> debbugs.gnu.org
> Date: Sun, 21 May 2023 14:32:46 +0800
>
> Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Mon, 22 May 2023 07:30:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 63555 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sat, 20 May 2023 13:35:56 -0400, Phillip Susi <phill <at> thesusis.net> said:
Phillip> Eli Zaretskii <eliz <at> 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
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Mon, 22 May 2023 09:27:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> 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...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Mon, 22 May 2023 10:06:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 63555 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 22 May 2023 17:26:27 +0800, Po Lu <luangruo <at> 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
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Mon, 22 May 2023 11:16:01 GMT)
Full text and
rfc822 format available.
Message #73 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Mon, 22 May 2023 17:26:27 +0800, Po Lu <luangruo <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Mon, 22 May 2023 11:29:01 GMT)
Full text and
rfc822 format available.
Message #76 received at 63555 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 22 May 2023 19:15:40 +0800, Po Lu <luangruo <at> yahoo.com> said:
Po Lu> Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>>> On Mon, 22 May 2023 17:26:27 +0800, Po Lu <luangruo <at> 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
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Mon, 22 May 2023 12:52:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Mon, 22 May 2023 13:45:01 GMT)
Full text and
rfc822 format available.
Message #82 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Mon, 22 May 2023 16:48:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 63555 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This patch works for me.
[auto-nw-mode.patch (text/x-diff, inline)]
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Mon, 22 May 2023 17:07:01 GMT)
Full text and
rfc822 format available.
Message #88 received at 63555 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 22 May 2023 12:44:40 -0400, Phillip Susi <phill <at> 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
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Tue, 23 May 2023 00:32:01 GMT)
Full text and
rfc822 format available.
Message #91 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Phillip Susi <phill <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Tue, 23 May 2023 15:00:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
> I think you need to check for them being non-empty as well
Good point.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Tue, 23 May 2023 15:01:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> Future GDK backends might use different environment variables -- or none
> at all.
So? Worry about the potential future when it comes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Wed, 24 May 2023 00:21:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Phillip Susi <phill <at> thesusis.net> writes:
> Po Lu <luangruo <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Thu, 25 May 2023 15:39:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Fri, 26 May 2023 01:02:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Phillip Susi <phill <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Fri, 26 May 2023 08:39:01 GMT)
Full text and
rfc822 format available.
Message #109 received at 63555 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 26 May 2023 09:00:57 +0800, Po Lu <luangruo <at> yahoo.com> said:
Po Lu> Phillip Susi <phill <at> 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
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Fri, 26 May 2023 15:56:01 GMT)
Full text and
rfc822 format available.
Message #112 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sat, 27 May 2023 00:50:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Phillip Susi <phill <at> thesusis.net> writes:
> Robert Pluim <rpluim <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Tue, 30 May 2023 17:35:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Wed, 31 May 2023 01:20:01 GMT)
Full text and
rfc822 format available.
Message #121 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Phillip Susi <phill <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Thu, 08 Jun 2023 06:03:02 GMT)
Full text and
rfc822 format available.
Message #124 received at 63555 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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
[Message part 2 (text/html, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 06 Jul 2023 11:24:07 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Peter Oliver <p.d.oliver <at> mavit.org.uk>
to
control <at> debbugs.gnu.org.
(Sun, 14 Jul 2024 19:55:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sun, 14 Jul 2024 21:02:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 63555 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
FWIW, here is a patch which causes Emacs to check that at least one of the environment variables WAYLAND_DISPLAY, DISPLAY, BROADWAY_DISPLAY is set before it will try to use PGTK for its initial window.
This patch is not suitable for merging, because it doesn’t consider what happens if you try to use PGTK on Windows or MacOS. However, people might find it useful if they’re not using one of those platforms.
This patch depends on the patch for bug 72118.
--
Peter Oliver
[0002-Fall-back-to-the-terminal-from-pure-GTK-when-no-disp.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sat, 20 Jul 2024 09:01:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 63555 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 14 Jul 2024 22:00:26 +0100 (BST)
> From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
>
> FWIW, here is a patch which causes Emacs to check that at least one of the environment variables WAYLAND_DISPLAY, DISPLAY, BROADWAY_DISPLAY is set before it will try to use PGTK for its initial window.
>
> This patch is not suitable for merging, because it doesn’t consider what happens if you try to use PGTK on Windows or MacOS. However, people might find it useful if they’re not using one of those platforms.
>
> This patch depends on the patch for bug 72118.
Po Lu, any comments?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sun, 04 Aug 2024 07:52:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Ping! Po Lu, any comments?
> Cc: 63555 <at> debbugs.gnu.org
> Date: Sat, 20 Jul 2024 12:00:35 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > Date: Sun, 14 Jul 2024 22:00:26 +0100 (BST)
> > From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
> >
> > FWIW, here is a patch which causes Emacs to check that at least one of the environment variables WAYLAND_DISPLAY, DISPLAY, BROADWAY_DISPLAY is set before it will try to use PGTK for its initial window.
> >
> > This patch is not suitable for merging, because it doesn’t consider what happens if you try to use PGTK on Windows or MacOS. However, people might find it useful if they’re not using one of those platforms.
> >
> > This patch depends on the patch for bug 72118.
>
> Po Lu, any comments?
>
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sat, 17 Aug 2024 08:20:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Ping! Ping! Po Lu, could you please respond?
> Cc: p.d.oliver <at> mavit.org.uk, 63555 <at> debbugs.gnu.org
> Date: Sun, 04 Aug 2024 10:50:53 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> Ping! Po Lu, any comments?
>
> > Cc: 63555 <at> debbugs.gnu.org
> > Date: Sat, 20 Jul 2024 12:00:35 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> >
> > > Date: Sun, 14 Jul 2024 22:00:26 +0100 (BST)
> > > From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
> > >
> > > FWIW, here is a patch which causes Emacs to check that at least one of the environment variables WAYLAND_DISPLAY, DISPLAY, BROADWAY_DISPLAY is set before it will try to use PGTK for its initial window.
> > >
> > > This patch is not suitable for merging, because it doesn’t consider what happens if you try to use PGTK on Windows or MacOS. However, people might find it useful if they’re not using one of those platforms.
> > >
> > > This patch depends on the patch for bug 72118.
> >
> > Po Lu, any comments?
> >
> >
> >
> >
>
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sat, 17 Aug 2024 08:23:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 63555 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Ping! Ping! Po Lu, could you please respond?
>
>> Cc: p.d.oliver <at> mavit.org.uk, 63555 <at> debbugs.gnu.org
>> Date: Sun, 04 Aug 2024 10:50:53 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>>
>> Ping! Po Lu, any comments?
>>
>> > Cc: 63555 <at> debbugs.gnu.org
>> > Date: Sat, 20 Jul 2024 12:00:35 +0300
>> > From: Eli Zaretskii <eliz <at> gnu.org>
>> >
>> > > Date: Sun, 14 Jul 2024 22:00:26 +0100 (BST)
>> > > From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
>> > >
>> > > FWIW, here is a patch which causes Emacs to check that at least one of the environment variables WAYLAND_DISPLAY, DISPLAY, BROADWAY_DISPLAY is set before it will try to use PGTK for its initial window.
>> > >
>> > > This patch is not suitable for merging, because it doesn’t consider what happens if you try to use PGTK on Windows or MacOS. However, people might find it useful if they’re not using one of those platforms.
>> > >
>> > > This patch depends on the patch for bug 72118.
>> >
>> > Po Lu, any comments?
>> >
>> >
>> >
>> >
>>
>>
>>
>>
This is fundamentally an improper approach because there's no predicting
what variables GTK will use in the future. Moreover, it will prevent
Emacs from starting in some Wayland sessions where WAYLAND_DISPLAY is
sometimes not set, and where the libwayland client/GTK simply tries
`wayland-0' or aborts if it's unavailable.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63555; Package
emacs.
(Sat, 31 Aug 2024 08:02:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 63555-done <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: p.d.oliver <at> mavit.org.uk, 63555 <at> debbugs.gnu.org
> Date: Sat, 17 Aug 2024 16:22:05 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Ping! Ping! Po Lu, could you please respond?
> >
> >> Cc: p.d.oliver <at> mavit.org.uk, 63555 <at> debbugs.gnu.org
> >> Date: Sun, 04 Aug 2024 10:50:53 +0300
> >> From: Eli Zaretskii <eliz <at> gnu.org>
> >>
> >> Ping! Po Lu, any comments?
> >>
> >> > Cc: 63555 <at> debbugs.gnu.org
> >> > Date: Sat, 20 Jul 2024 12:00:35 +0300
> >> > From: Eli Zaretskii <eliz <at> gnu.org>
> >> >
> >> > > Date: Sun, 14 Jul 2024 22:00:26 +0100 (BST)
> >> > > From: Peter Oliver <p.d.oliver <at> mavit.org.uk>
> >> > >
> >> > > FWIW, here is a patch which causes Emacs to check that at least one of the environment variables WAYLAND_DISPLAY, DISPLAY, BROADWAY_DISPLAY is set before it will try to use PGTK for its initial window.
> >> > >
> >> > > This patch is not suitable for merging, because it doesn’t consider what happens if you try to use PGTK on Windows or MacOS. However, people might find it useful if they’re not using one of those platforms.
> >> > >
> >> > > This patch depends on the patch for bug 72118.
> >> >
> >> > Po Lu, any comments?
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >>
>
> This is fundamentally an improper approach because there's no predicting
> what variables GTK will use in the future. Moreover, it will prevent
> Emacs from starting in some Wayland sessions where WAYLAND_DISPLAY is
> sometimes not set, and where the libwayland client/GTK simply tries
> `wayland-0' or aborts if it's unavailable.
No further comments within 2 weeks, so I'm now closing this bug.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 28 Sep 2024 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 225 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.