patch to make emacs proceed if DISPLAY is unreachable

patch to make emacs proceed if DISPLAY is unreachable

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 802 bytes --]

Hi: In the past, I've had to administer various machines with NFS mounted 
homedirs, and from time to time when su'ing I've been bitten by the fact
that altough DISPLAY was set, emacs couldn't read my .Xauthority
file (as it was on NHS). I've had a look at the code, and figure oud what's
going on, (I think), and put together this patch to make emacs proceed
as if -nw had been supplied if DISPLAY is unreachable for some reason.

This behaviour does not apply to displays explicitly provided by -d
on the command line, only to implicit DISPLAY settings.

I find I prefer this behaviour, so I'm submitting the patch,
hopefully the emacs team will consider either using this patch
or implementing similar behaviour themselves (I think the patch
is without side effect, but I could be wrong).

-- 
Vivek

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2195 bytes --]

diff -urbB emacs21-21.4a/src/emacs.c emacs21-21.4a.displaylenience/src/emacs.c
--- emacs21-21.4a/src/emacs.c	2002-08-29 20:27:07.000000000 +0100
+++ emacs21-21.4a.displaylenience/src/emacs.c	2006-03-06 00:05:23.000000000 +0000
@@ -45,6 +45,10 @@
 #include "intervals.h"
 #include "buffer.h"
 
+#ifdef HAVE_X_WINDOWS
+#include "xterm.h"
+#endif
+
 #include "systty.h"
 #include "blockinput.h"
 #include "syssignal.h"
@@ -1268,6 +1272,14 @@
 
     /* Don't actually discard this arg.  */
     skip_args = count_before;
+    
+    /* Do NOT be lenient if the user explicitly asked for a named display */
+    if( display_arg != 1 )
+      if( x_display_ok(displayname) == 0 ) {
+        inhibit_window_system = 1;
+        fprintf( stderr,
+                 "DISPLAY unavailable, simulating -nw\n", displayname );
+      }
   }
 #endif
 
diff -urbB emacs21-21.4a/src/xterm.c emacs21-21.4a.displaylenience/src/xterm.c
--- emacs21-21.4a/src/xterm.c	2002-10-15 15:21:45.000000000 +0100
+++ emacs21-21.4a.displaylenience/src/xterm.c	2006-03-06 00:07:40.000000000 +0000
@@ -14156,6 +14156,24 @@
 }
 #endif
 
+int
+x_display_ok (display)
+    const char * display;
+{
+    int dpy_ok = 1;
+    Display *dpy;
+    char *display_name = display || getenv("DISPLAY");
+
+    if( !display_name ) 
+      return 0;
+
+    if( dpy = XOpenDisplay (display) )
+      XCloseDisplay( dpy );
+    else
+      dpy_ok = 0;
+    return dpy_ok;
+}
+
 struct x_display_info *
 x_term_init (display_name, xrm_option, resource_name)
      Lisp_Object display_name;
diff -urbB emacs21-21.4a/src/xterm.h emacs21-21.4a.displaylenience/src/xterm.h
--- emacs21-21.4a/src/xterm.h	2002-02-22 10:41:44.000000000 +0000
+++ emacs21-21.4a.displaylenience/src/xterm.h	2006-03-06 00:07:40.000000000 +0000
@@ -378,6 +378,7 @@
 extern struct x_display_info *x_display_info_for_name P_ ((Lisp_Object));
 
 extern struct x_display_info *x_term_init P_ ((Lisp_Object, char *, char *));
+extern int x_display_ok  P_ ((const char *));
 
 extern Lisp_Object x_list_fonts P_ ((struct frame *, Lisp_Object, int, int));
 extern void select_visual P_ ((struct x_display_info *));

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: patch to make emacs proceed if DISPLAY is unreachable

[Jan D.]

Vivek Dasmohapatra wrote:
> Hi: In the past, I've had to administer various machines with NFS 
> mounted homedirs, and from time to time when su'ing I've been bitten by 
> the fact
> that altough DISPLAY was set, emacs couldn't read my .Xauthority
> file (as it was on NHS). I've had a look at the code, and figure oud what's
> going on, (I think), and put together this patch to make emacs proceed
> as if -nw had been supplied if DISPLAY is unreachable for some reason.

Hmm, I prefer the old behaviour.  I often set DISPLAY to a remote machine but 
forget to fix .Xauthority.  I don't want -nw to happen then, I just want Emacs 
to tell me it can not connect to that display.

	Jan D.

Re: patch to make emacs proceed if DISPLAY is unreachable

[Giorgos Keramidas]

On 2006-03-07 08:31, "Jan D." <jan.h.d@swipnet.se> wrote:
>Vivek Dasmohapatra wrote:
>> Hi: In the past, I've had to administer various machines with NFS
>> mounted homedirs, and from time to time when su'ing I've been bitten
>> by the fact that altough DISPLAY was set, emacs couldn't read my
>> .Xauthority file (as it was on NHS). I've had a look at the code, and
>> figure oud what's going on, (I think), and put together this patch to
>> make emacs proceed as if -nw had been supplied if DISPLAY is
>> unreachable for some reason.
>
> Hmm, I prefer the old behaviour.  I often set DISPLAY to a remote machine
> but forget to fix .Xauthority.  I don't want -nw to happen then, I just
> want Emacs to tell me it can not connect to that display.

How about making this customizable then?

I haven't had the time to look into the DISPLAY initialization parts.
If they are used before .emacs is loaded it may be a bit trickier than
what I initially thought.  But when users may want a diversion from the
default behavior, then a customizable option is what's called for, IMHO :)

- Giorgos

Re: patch to make emacs proceed if DISPLAY is unreachable

[Vivek Dasmohapatra]

On Tue, 7 Mar 2006, Giorgos Keramidas wrote:

> How about making this customizable then?
>
> I haven't had the time to look into the DISPLAY initialization parts.
> If they are used before .emacs is loaded it may be a bit trickier than
> what I initially thought.  But when users may want a diversion from the
> default behavior, then a customizable option is what's called for, IMHO :)

This happens well before any customisation. In fact, it happens before
the lisp engine is started and we enter normal-top-level.

1) Command lines are parsed

2) if no display is required, the terminal is initialised

3) we enter elisp at normal-top-level

4) command-line is called :
      NOW the elisp engine parses the command line and creates a GUI frame
      if necessary, or defaults to using the terminal frame.


Ideally, this could all be fixed after 4, unfortunaltely the terminal is 
already uninitialised/intialised at 2, so even if we make display
failure non-fatal at 4, the terminal/frames aren't in the right state
for us to use anyway.

I worked around this by inserting the kludge at 1.5.

It would require much more major surgery to make this subject to 
customisation, it's all quite deep down inside emacs.

Re: patch to make emacs proceed if DISPLAY is unreachable

[Giorgos Keramidas]

On 2006-03-07 16:30, Vivek Dasmohapatra <vivek@etla.org> wrote:
>On Tue, 7 Mar 2006, Giorgos Keramidas wrote:
>> How about making this customizable then?
>>
>> I haven't had the time to look into the DISPLAY initialization parts.
>> If they are used before .emacs is loaded it may be a bit trickier than
>> what I initially thought.  But when users may want a diversion from the
>> default behavior, then a customizable option is what's called for, IMHO :)
>
> This happens well before any customisation. In fact, it happens before
> the lisp engine is started and we enter normal-top-level.

I remember the 'hack' we had to use for the 'visible-cursor option, so I
was sort of had expected this to be the case :-(

> 1) Command lines are parsed
>
> 2) if no display is required, the terminal is initialised
>
> 3) we enter elisp at normal-top-level
>
> 4) command-line is called :
>      NOW the elisp engine parses the command line and creates a GUI frame
>      if necessary, or defaults to using the terminal frame.
>
> Ideally, this could all be fixed after 4, unfortunaltely the terminal is
> already uninitialised/intialised at 2, so even if we make display
> failure non-fatal at 4, the terminal/frames aren't in the right state
> for us to use anyway.
>
> I worked around this by inserting the kludge at 1.5.
>
> It would require much more major surgery to make this subject to
> customisation, it's all quite deep down inside emacs.

I see.  Thanks for the explanation and the very fast reply.  Let us not
waste too much time & effort, possibly inserting bugs in the process
too, for making this a customizable option then.

I think our safest bet is to leave this up to the user, and keep using
the -nw command-line option for disabling any use of DISPLAY.

- Giorgos