Re: Re: xterm and 7-bit control codes
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/
Re: Re: xterm and 7-bit control codes
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: xterm and 7-bit control codes
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/
