xterm and 7-bit control codes

xterm and 7-bit control codes

[Ryan Johnson]

  Hi all,

I'm running into a strange one...

At some point in the past (on linux because I didn't know about cygwin 
yet), xterm used to send the following control sequence for a mouse 
click at row 1, col 250

ESC [ M SPC \303\206 ! ESC [ M # \303\206 !

 From what I could piece together, the formula for the x position was:

\40+x (x < 96)
\300+X/64 \200+X%64 (otherwise)

In other words, the first 96 characters were encoded as single octets, 
with all later ones encoded as an octet pair.

I recently got back to using a wide monitor for the first time in years, 
and discovered that my hacks to emacs' xterm-mouse-mode no longer worked 
well because the two-octet code has been replaced by zero:

ESC [ M SPC \000 ! ESC [ M # \000 !

This makes it hard to use the mouse on the right side of a large 
terminal window...

I've verified that it's not emacs doing this (nor bash) by running 
directly (xterm -e) a small C utility which sends the mouse activation 
sequence and then converts stdin to an octet stream. Mouse clicks arrive 
just as emacs reported.

Am I smoking something or has something about this control sequence 
changed in the last 5-6 years? I wonder if it has something to do with 
UTF-8 handling and if X changed somehow...

The xfree86 control sequence documentation is less than helpful here 
[1]. For "normal tracking mode" it says:
> On button press or release, xterm sends CSI M C b C x C y . The low 
> two bits of C b encode button information: 0=MB1 pressed, 1=MB2 
> pressed, 2=MB3 pressed, 3=release. The next three bits encode the 
> modifiers which were down when the button was pressed and are added 
> together: 4=Shift, 8=Meta, 16=Control. Note however that the shift and 
> control bits are normally unavailable because xterm uses the control 
> modifier with mouse for popup menus, and the shift modifier is used in 
> the default translations for button events. The Meta modifier 
> recognized by xterm is the mod1 mask, and is not necessarily the 
> "Meta" key (see xmodmap). C x and C y are the x and y coordinates of 
> the mouse event, encoded as in X10 mode.
In X10 mode:
> On button press, xterm sends CSI M C b C x C y (6 characters). C b is 
> button−1. C x and C y are the x and y coordinates of the mouse when 
> the button was pressed.

I remember reading the same thing all those years ago and being annoyed 
even then because it was so vague. Clearly the terminal was sending more 
than 6 octets (who knows how many "characters" that's supposed to be), 
and the spec doesn't mention the fact that all coordinates are offset by 
\40. How UTF-8, Unicode, and other encoding complexities fit in I have 
no clue...

This may turn out to have nothing to do with cygwin/X; if so I'd 
appreciate ideas on where to send it next...

Ideas?
Ryan

[1] http://www.xfree86.org/current/ctlseqs.html#Mouse%20Tracking




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

Re: xterm and 7-bit control codes

[Thomas Dickey]

On Thu, 12 Aug 2010, Ryan Johnson wrote:

> Hi all,
>
> I'm running into a strange one...
>
> At some point in the past (on linux because I didn't know about cygwin yet), 
> xterm used to send the following control sequence for a mouse click at row 1, 
> col 250
>
> ESC [ M SPC \303\206 ! ESC [ M # \303\206 !
>
> From what I could piece together, the formula for the x position was:
>
> \40+x (x < 96)
> \300+X/64 \200+X%64 (otherwise)
>
> In other words, the first 96 characters were encoded as single octets, with 
> all later ones encoded as an octet pair.

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.

(On the other hand, whatever application you were using at the time may
have translated the characters in that manner).

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

Re: Re: xterm and 7-bit control codes

[Ryan Johnson]

  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/

Re: Re: xterm and 7-bit control codes

[Thomas Dickey]

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/