[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cannot connect to X server

From: Olivier Lecarme
Subject: cannot connect to X server
Date: Mon, 26 Nov 2001 12:21:08 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryomae) APEL/10.3 Emacs/21.1 (alphaev6-dec-osf4.0f) MULE/5.0 (SAKAKI)

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the address@hidden mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.1.1 (alphaev6-dec-osf4.0f, X toolkit)
 of 2001-10-22 on uranie.unice.fr
configured using `configure  --prefix=/usr/local/GNU/emacs-21.1 
--with-x-toolkit=athena --without-tiff'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: fr_FR.ISO8859-1
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Same symptoms as in my previous message, but here the phenomenon is
more apparent. Here is the exact contents of an xterm window :

uranie(~/GNU/emacs-21.1/share/emacs/21.1/site-lisp)31: emacs21 site-start.el&
[1] 11236
uranie(~/GNU/emacs-21.1/share/emacs/21.1/site-lisp)32: emacs: Cannot connect to 
X server presto:0.0.
Check the DISPLAY environment variable or use `-d'.
Also use the `xhost' program to verify that it is set to permit
connections from your machine.

[1]  + 11236 exit 1     emacs21 site-start.el
uranie(~/GNU/emacs-21.1/share/emacs/21.1/site-lisp)32: vared DISPLAY
uranie(~/GNU/emacs-21.1/share/emacs/21.1/site-lisp)33: xhost
access control enabled, only authorized clients can connect
uranie(~/GNU/emacs-21.1/share/emacs/21.1/site-lisp)34: emacs21 site-start.el&
[1] 11243

Thus the same command, after a delay of a very few seconds and no
change in the environment, has a different behavior.

                        Olivier Lecarme

reply via email to

[Prev in Thread] Current Thread [Next in Thread]