bug#7117: 23.2.2 mangles terminal escape sequences

[Ryan Johnson <ryanjohn@ece.cmu.edu>]

  On 9/28/2010 6:53 AM, Ryan Johnson wrote:
>  On 9/27/2010 10:52 PM, Stefan Monnier wrote:
>>> 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?
> 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.
>
> This matches my expectations, since bug #6920 arises before any coding 
> system touches the input.
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.

Thanks,
Ryan