>>>> "jwz" == Jamie Zawinski <jwz(a)jwz.org>
jwz> Martin Buchholz wrote:
jwz> Since upgrading from RH 7.2 to RH 8.0, I can no
longer compose long
jwz> command lines in tcsh when running in an XEmacs *shell* buffer. I don't
jwz> know whether this is a bug in tcsh, or in readline, or what, but it does
jwz> not happen with bash.
jwz> Aha! Turns out it's xemacs's fault.
>> xemacs tries to circumvent the system limit. If the command line is
>> longer than 200 or so, it sends the command line in chunks of 200,
>> with a '^D' character in between (!). This insanity has mostly worked
>> for the past decade. "Usually" the '^D's are discarded.
>> csh has always been a little special, because
'^D' also does file
>> completion. I remember that ten years ago,
>> unset filec
jwz> Bingo. "unset filec" fixes it.
jwz> So if xemacs were either:
jwz> - just sending all the bytes at once; or
jwz> - sending them in chunks, but without the extra ^D
If XEmacs sends more than MAX_CANON (usually 256) bytes all at once to
the tty, it typically gets wedged in a most horrible way.
Unfortunately, sending them in chunks without ^D has the same effect.
EOF (Control-d or ASCII EOT) may be used to generate an
end-of-file from a terminal. When received, all the
characters waiting to be read are immediately passed
to the program, without waiting for a newline, and the
EOF is discarded. Thus, if no characters are waiting
(that is, the EOF occurred at the beginning of a line)
zero characters are passed back, which is the standard
end-of-file indication. Unless escaped, the EOF char-
acter is not echoed. Because EOT is the default EOF
character, this prevents terminals that respond to EOT
from hanging up.
You can see the effect even today by doing:
bash -noediting (or Solaris /bin/sh)
hold down the 'x' key. (or paste some text without newlines repeatedly)
Eventually (1024 chars on Linux; 256 on Solaris) the xterm will refuse
to allow any more input and will just beep at you.
jwz> then it would work fine without "unset filec".
The above description is only correct if icanon mode is turned on in
the tty. That used to be generally true, but these days shells like
to process their input characters themselves by default.
The correct way to fix this bug is for XEmacs to check whether the tty
is in icanon mode and the EOF character is defined. Then, and ONLY
then, should the ^D trick be used to avoid MAX_CANON.
It is probably also a bug that ICANON is set by XEmacs when it
initializes a pty. If a user explicitly inserts a literal ^W into the
shell input buffer, it is more likely that they want this passed to
the shell than that they want to have the previous word be discarded
by the tty. Emacs is a better editor than the tty -- the user already
I feel vaguely responsible for this, so I will make a patch.