This is the mail archive of the cygwin-xfree mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

xterm and 7-bit control codes


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]