This is the mail archive of the
cygwin-xfree
mailing list for the Cygwin XFree86 project.
xterm and 7-bit control codes
- From: Ryan Johnson <ryanjohn at ece dot cmu dot edu>
- To: cygwin-xfree <cygwin-xfree at cygwin dot com>
- Date: Thu, 12 Aug 2010 16:49:44 +0200
- Subject: xterm and 7-bit control codes
- Reply-to: cygwin-xfree at cygwin dot com
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/