Re: Re: xterm and 7-bit control codes

[Thomas Dickey <dickey at his dot com>]

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/