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/