|
From: | Ryan Johnson |
Subject: | bug#7117: 23.2.2 mangles terminal escape sequences |
Date: | Thu, 30 Sep 2010 13:37:40 +0200 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 |
On 9/28/2010 6:53 AM, Ryan Johnson wrote:
Any hints on where the problem might lurk? I poked around a little but without luck -- the functions that power read-char are many hundreds of lines long and seem to weave between lisp and C at regular intervals. I'm willing to go source diving but it's a bit daunting to wade into the C code again without a starting reference.On 9/27/2010 10:52 PM, Stefan Monnier wrote:No. In fact, the solaris machine which I ran the example on defaults to `no-conversion' (an alias of binary iirc) for some reason. Sorry, I forgot to mention before.Steps to reproduce: 1. ssh to a machine with emacs-23 installed (I suspect slower networks would expose this more, but the bug bites me even over intranet)2. compile tee-input.c (see below) into a shared library (on solaris:`cc -g -G -xcode=pic13 -ldl -hlibtee-input.so tee-input.c -g -o libtee-input.so') 3. invoke `LD_PRELOAD=libtee-input.so emacs -nw -Q 2>input.txt' 4. M-x xterm-mouse-mode 5. flick the mouse scroll wheel hard, so it generates many ticks in quick succession (note the garbage that results) 6. M-x show-lossage (note the mangled escape sequences) 7. C-x C-c 8. Examine input.txt (note the intact escape sequences)Does (set-keyboard-coding-system 'binary) circumvent the problem?This matches my expectations, since bug #6920 arises before any coding system touches the input.
Thanks, Ryan
[Prev in Thread] | Current Thread | [Next in Thread] |