Re: Re: xterm and 7-bit control codes

[Ryan Johnson <ryanjohn at ece dot cmu dot edu>]

 On 8:59 PM, Thomas Dickey wrote:
> As far as I know, xterm's never sent more than one byte for either x/y in
> a button event.  Ditto for rxvt.  It sounds like a useful idea, except 
> that it would of course be incompatible with the existing applications.
> So it would have to be enabled by a new control sequence.
Hehe... very true about breaking existing apps. All those years ago the 
extra octet kick-started everything by confusing emacs (well, 
xterm-mouse-mode, really). I started looking at the character stream and 
reverse-engineered the above formula while trying to get rid of all the 
ascii garbage that polluted my buffers after stray mouse clicks. Only 
then did I realize I could exploit (rather than suppress) the extra 
octets to make large terminals behave better...

> (On the other hand, whatever application you were using at the time may
> have translated the characters in that manner).
I dug up an old .emacs, and it actually mentions gnu screen. If so, 
that's definitely been "fixed" because I specifically tested screen on 
several machines (cygwin, solaris, linux), plus rxvt and the gnome 
terminal***) before posting here. Any ideas what other terminal 
emulators I might test?

Side note: how much pain would it be asking for if I tried to add the 
double-octet behavior to xterm as a feature? Would it be better to 
tackle rxvt? Or would it be man-weeks of work no matter what and I 
should just drop it?

Thanks,
Ryan

*** testing gnome terminal was hilarious: enabling mouse support and 
clicking on the wrong position sends a control sequence containing ^Z, 
which duly backgrounds the app!


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/