xterm and 7-bit control codes
Thomas Dickey
dickey@his.com
Sat Aug 14 11:57:00 GMT 2010
On Sat, 14 Aug 2010, Ryan Johnson wrote:
> 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?
Not offhand. The only prior discussion I recall in that area was the
1-byte limit. It might have been someone's more/less private patch to
screen - to be usable with screen in the first place, it has to be aware
of the control sequence (otherwise it tends to filter things out). The
mouse control sequences are a special case, since they don't have a final
character.
> 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?
It didn't sound like a lot of work: a case-statement entry in dpmodes
(charproc.c) to enable/disable it, and a few lines of code in EditorButton
(button.c) plus updating ctlseqs.ms).
>
> 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!
;-)
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
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