# HG changeset patch
# User Stefan Monnier <monnier@iro.umontreal.ca>
# Date 1280945407 -7200
# Node ID 7b98612e882764b07253e714071932bf590aa21a
# Parent  2c821d4f47fe4aca29e26ddb07ffa6f92ad4477d
* src/sysdep.c (child_setup_tty): Comment-out left-over non-ICANON code.

diff -r 2c821d4f47fe -r 7b98612e8827 src/ChangeLog
--- a/src/ChangeLog	Tue Aug 03 23:54:16 2010 +0200
+++ b/src/ChangeLog	Wed Aug 04 20:10:07 2010 +0200
@@ -1,3 +1,7 @@
+2010-08-04  Stefan Monnier  <monnier@iro.umontreal.ca>
+
+	* sysdep.c (child_setup_tty): Comment-out left-over non-ICANON code.
+
 2010-08-03  Johan Bockgård  <bojohan@gnu.org>
 
 	* data.c (Flocal_variable_p): Handle variable aliases correctly.
diff -r 2c821d4f47fe -r 7b98612e8827 src/sysdep.c
--- a/src/sysdep.c	Tue Aug 03 23:54:16 2010 +0200
+++ b/src/sysdep.c	Wed Aug 04 20:10:07 2010 +0200
@@ -503,26 +503,29 @@
   s.main.c_cflag = (s.main.c_cflag & ~CBAUD) | B9600; /* baud rate sanity */
 #endif /* AIX */
 
-  /* We used to enable ICANON (and set VEOF to 04), but this leads to
-     problems where process.c wants to send EOFs every once in a while
-     to force the output, which leads to weird effects when the
+  /* We originally enabled ICANON (and set VEOF to 04), and then had
+     proces.c send additional EOF chars to flush the output when faced
+     with long lines, but this leads to weird effects when the
      subprocess has disabled ICANON and ends up seeing those spurious
      extra EOFs.  So we don't send EOFs any more in
-     process.c:send_process, and instead we disable ICANON by default,
-     so if a subsprocess sets up ICANON, it's his problem (or the Elisp
-     package that talks to it) to deal with lines that are too long.  */
-  /* There is no more "send eof to flush" going on (which is wrong and
-     unportable in itself), and disabling ICANON breaks a lot of stuff
-     and shows literal ^D in many cases.  The correct way to handle too
-     much output is to buffer what could not be written and then write it
-     again when select returns ok for writing.  This has it own set of
-     problems. Write is now asynchronous, is that a problem?
-     How much do we buffer, and what do we do when that limit is reached?  */
+     process.c:send_process.  First we tried to disable ICANON by
+     default, so if a subsprocess sets up ICANON, it's his problem (or
+     the Elisp package that talks to it) to deal with lines that are
+     too long.  But this disables some features, such as the ability
+     to send EOF signals.  So we re-enabled ICANON but there is no
+     more "send eof to flush" going on (which is wrong and unportable
+     in itself).  The correct way to handle too much output is to
+     buffer what could not be written and then write it again when
+     select returns ok for writing.  This has it own set of
+     problems.  Write is now asynchronous, is that a problem?  How much
+     do we buffer, and what do we do when that limit is reached?  */
 
   s.main.c_lflag |= ICANON;	/* Enable line editing and eof processing */
   s.main.c_cc[VEOF] = 'D'&037;	/* Control-D */
+#ifdef 0	    /* These settins only apply to non-ICANON mode. */
   s.main.c_cc[VMIN] = 1;
   s.main.c_cc[VTIME] = 0;
+#endif
 
 #else /* not HAVE_TERMIO */