changeset 83028:bf5b5fb49420

Don't exit Emacs when the X display is closed during a tty-X combo session. src/xterm.c (x_delete_display): Fix semantic typo. (x_connection_closed): When deciding whether or not to shut down Emacs, check for remaining elements in display_list, not x_display_list. git-archimport-id: [e-mail]--2004/emacs--multi-tty--0--patch-68

--- a/README.multi-tty	Sun Jan 25 01:17:40 2004 +0000
+++ b/README.multi-tty	Mon Jan 26 07:17:34 2004 +0000
@@ -7,7 +7,6 @@
 Emacs session.
 
 Some use cases:
-
 Emacs is notoriously slow at startup, so most people use another
 editor or emacsclient for quick editing jobs from the console.
 Unfortunately, emacsclient was very awkward to use, because it did not
@@ -21,7 +20,6 @@
 and check their messages without opening a remote X frame or resorting
 to gnus-slave.
 
-
 WHO IS DOING IT
 ---------------
 
@@ -56,11 +54,11 @@
 STATUS
 ------
 
-Multi-tty support is stable, I think most of the problems were fixed.
-(It still needs testing on other architectures, though.)  Simultaneous
-X and tty frame support works fine, although there are some small
-issues.  Emacsclient has been extended to support opening a new
-terminal frame.
+The branch is now very stable and almost full-featured. I hope the
+major problems were fixed.  (It still needs testing on other
+architectures, though.)  Both multiple tty device support and
+simultaneous X and tty frame support works fine.  Emacsclient has been
+extended to support opening a new terminal frame.
 
 
 Please let me know if you find any bugs in this branch.
@@ -94,6 +92,20 @@
 always run emacs from gdb, so that you'll have a live instance to
 debug if something goes wrong.  Please send me your bug reports.
 
+I think the best way to use the new Emacs is to have it running inside
+a disconnected GNU screen session, and always use emacsclient for
+normal work.  This way not a single keystroke of your work will be
+lost if the display device that you are using crashes, or the network
+connection times out, or whatever.  As long as the server that runs
+your Emacs remains up, all your buffers remain exactly as they were
+before the crash, and you can continue working as if nothing had
+happened.  (I had an extremely unstable X server for some time while I
+was developing these patches, and running Emacs this way has saved me
+a number of M-x recover-session invocations.)
+
+(I am thinking about introducing a --daemon option to get rid of the
+above screen dependency.)
+
 Problems:
 
 	* Suspending Emacs is disabled if there are multiple tty
@@ -182,6 +194,13 @@
    extend emacsclient to handle suspend/resume.  A `kill -STOP' almost
    works right now.)
 
+** Clean up the frame-local variable system.  I think it's ugly and
+   error-prone.  But maybe I just haven't yet fully understood it.
+
+** Add an elaborate mechanism for display-local variables.  (There are
+   already a few of these; search for `terminal-local' in the Elisp
+   manual.)
+
 ** Move baud_rate to struct display.
 
 ** Implement support for starting an interactive Emacs session without
@@ -610,4 +629,9 @@
 
    (Fixed.)
 
+-- Don't exit Emacs when the last X connection fails during a
+   multi-display session.
+
+   (Fixed.)
+
 ;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d

--- a/src/xterm.c	Sun Jan 25 01:17:40 2004 +0000
+++ b/src/xterm.c	Mon Jan 26 07:17:34 2004 +0000
@@ -7866,7 +7866,7 @@
 
   x_uncatch_errors (dpy, count);
 
-  if (x_display_list == 0)
+  if (display_list == 0)
     {
       fprintf (stderr, "%s\n", error_msg);
       shut_down_emacs (0, 0, Qnil);
@@ -10748,7 +10748,7 @@
     /* Delete the generic struct display for this X display. */
     struct display *d;
     for (d = display_list; d; d = d->next_display)
-      if (d->type == output_x_window && d->display_info.x != dpyinfo)
+      if (d->type == output_x_window && d->display_info.x == dpyinfo)
         {
           delete_display (d);
           break;