Fix C-g during `make-network-process'. (Reported by Mark Plaksin.)

* src/process.c (Fmake_network_process): Don't unrequest_sigio on modern
  systems.

* src/keyboard.c (Fset_input_interrupt_mode): Cosmetic change.

* src/sysdep.c (request_sigio): Make it a no-op if noninteractive.
  (unrequest_sigio): Make it a no-op if noninteractive.

git-archimport-id: [email protected]/emacs--multi-tty--0--patch-494

4 files changed, 41 insertions, 24 deletions

diff --git a/README.multi-tty b/README.multi-tty
index 7ad6bf5b31..261aa84ae7 100644
--- a/README.multi-tty
+++ b/README.multi-tty
@@ -401,6 +401,16 @@ is probably not very interesting for anyone else.)
 THINGS TO DO
 ------------
 
+** Understand how `quit_throw_to_read_char' works, and fix any bugs
+   that come to light.
+
+** Replace wrong_kboard_jmpbuf with a special return value of
+   read_char.  It is absurd that we use setjmp/longjmp just to return
+   to the immediate caller.
+
+** See if getcjmp can be eliminated somehow.  Why does Emacs allow
+   asynchronous input processing while it's reading input anyway?
+
 ** `delete-frame' events are handled by `special-event-map'
    immediately when read by `read_char'.  This is fine but it prevents
    higher-level keymaps from binding that event to get notified of the
@@ -688,15 +698,6 @@ THINGS TO DO
 
 ** Do a grep on XXX and ?? for more issues.
 
-** Understand Emacs's low-level input system (it's black magic) :-)
-   What exactly does interrupt_input do?  I tried to disable it for
-   raw secondary tty support, but it does not seem to do anything
-   useful.  (Update: Look again. X unconditionally enables this, maybe
-   that's why raw terminal support is broken again.  I really do need
-   to understand input.)
-   (Update: I am starting to understand the read_key_sequence->read-char
-   ->kbd_buffer_get_event->read_avail_input->read_socket_hook path.  Yay!)
-
 ** flow-ctrl.el must be updated.
 
 ** Fix stuff_char for multi-tty.  Doesn't seem to be of high priority.
@@ -1435,6 +1436,22 @@ DIARY OF CHANGES
    kills the terminal.  There was no bug here, but I rewrote the whole
    single_kboard mess anyway.) (patch-489)
 
+-- Understand Emacs's low-level input system (it's black magic) :-)
+   What exactly does interrupt_input do?  I tried to disable it for
+   raw secondary tty support, but it does not seem to do anything
+   useful.  (Update: Look again. X unconditionally enables this, maybe
+   that's why raw terminal support is broken again.  I really do need
+   to understand input.)
+   (Update: I am starting to understand the read_key_sequence->read-char
+   ->kbd_buffer_get_event->read_avail_input->read_socket_hook path.  Yay!)
+
+   (Update: OK, it all seems so easy now (NOT).  Input could be done
+   synchronously (with wait_reading_process_input), or asynchronously
+   by SIGIO or polling (SIGALRM).  C-g either sets the Vquit_flag,
+   signals a 'quit condition (when immediate_quit), or throws to
+   `getcjmp' when Emacs was waiting for input when the C-g event
+   arrived.)
+
 
 ;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d
 
diff --git a/src/keyboard.c b/src/keyboard.c
index d923cfd31a..6c94ef30ef 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -10741,11 +10741,8 @@ See also `current-input-mode'.  */)
   int new_interrupt_input;
 #ifdef SIGIO
 /* Note SIGIO has been undef'd if FIONREAD is missing.  */
-  if (0
 #ifdef HAVE_X_WINDOWS
-      || x_display_list != NULL
-#endif
-      )
+  if (x_display_list != NULL)
     {
       /* When using X, don't give the user a real choice,
 	 because we haven't implemented the mechanisms to support it.  */
@@ -10756,6 +10753,7 @@ See also `current-input-mode'.  */)
 #endif /* NO_SOCK_SIGIO */
     }
   else
+#endif
     new_interrupt_input = !NILP (interrupt);
 #else /* not SIGIO */
   new_interrupt_input = 0;
@@ -10787,7 +10785,7 @@ See also `current-input-mode'.  */)
     }
   return Qnil;
 }
-  
+
 DEFUN ("set-output-flow-control", Fset_output_flow_control, Sset_output_flow_control, 1, 2, 0,
        doc: /* Enable or disable ^S/^Q flow control for output to TERMINAL.
 If FLOW is non-nil, flow control is enabled and you cannot use C-s or
diff --git a/src/process.c b/src/process.c
index 05ea7c863b..9d4e203452 100644
--- a/src/process.c
+++ b/src/process.c
@@ -3086,6 +3086,10 @@ usage: (make-network-process &rest ARGS)  */)
 
  open_socket:
 
+#ifdef __ultrix__
+  /* Previously this was compiled unconditionally, but that seems
+     unnecessary on modern systems, and `unrequest_sigio' was a noop
+     under X anyway. --lorentey */
   /* Kernel bugs (on Ultrix at least) cause lossage (not just EINTR)
      when connect is interrupted.  So let's not let it get interrupted.
      Note we do not turn off polling, because polling is only used
@@ -3102,6 +3106,7 @@ usage: (make-network-process &rest ARGS)  */)
       record_unwind_protect (unwind_request_sigio, Qnil);
       unrequest_sigio ();
     }
+#endif
 
   /* Do this in case we never enter the for-loop below.  */
   count1 = SPECPDL_INDEX ();
diff --git a/src/sysdep.c b/src/sysdep.c
index 956323f3a3..25db4c7308 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -1037,12 +1037,8 @@ reset_sigio (fd)
 void
 request_sigio ()
 {
-  /* XXX read_socket_hook is not global anymore.  Is blocking SIGIO
-     bad under X? */
-#if 0
-  if (noninteractive || read_socket_hook)
+  if (noninteractive)
     return;
-#endif
 
 #ifdef SIGWINCH
   sigunblock (sigmask (SIGWINCH));
@@ -1055,13 +1051,14 @@ request_sigio ()
 void
 unrequest_sigio (void)
 { 
-  /* XXX read_socket_hook is not global anymore.  Is blocking SIGIO
-     bad under X? */
-#if 0
-  if (noninteractive || read_socket_hook)
+  if (noninteractive)
+    return;
+
+#if 0 /* XXX What's wrong with blocking SIGIO under X?  */
+  if (x_display_list)
     return;
 #endif
-  
+
 #ifdef SIGWINCH
   sigblock (sigmask (SIGWINCH));
 #endif