xterm and 7-bit control codes
Ryan Johnson
ryanjohn@ece.cmu.edu
Fri Aug 13 22:48:00 GMT 2010
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/
More information about the Cygwin-xfree
mailing list