[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7117: 23.2.2 mangles terminal escape sequences

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: Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2

 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
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
   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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]