Martin Buchholz wrote:
jwz>
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82610
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.
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
Bingo. "unset filec" fixes it.
So if xemacs were either:
- just sending all the bytes at once; or
- sending them in chunks, but without the extra ^D
then it would work fine without "unset filec".
Lessons? In addition to the stuff in my previous message, we might
want to fiddle with
stty imaxbel/stty -imaxbel
stty ixoff/stty -ixoff
This stuff didn't affect anything.
tcsh-6.12-4
xemacs-21.4.12-6
Red Hat Linux release 9 (Shrike)
Linux 2.4.20-8smp #1 SMP Thu Mar 13 16:43:01 EST 2003 i686 athlon i386
--
Jamie Zawinski
jwz(a)jwz.org
http://www.jwz.org/
jwz(a)dnalounge.com
http://www.dnalounge.com/