GNOME Bugzilla – Bug 662423
Support URXVT Extended Mouse Tracking (DEC Code 1015)
Last modified: 2012-08-21 17:19:27 UTC
gnome-terminal does not seem to support the "DEC 1005" command, after which it should report all mouse tracking events coordinates in UTF-8. Its not that windows wider than 223 columns are all too common. But I just wanted to teach node.js to understand terminal mouse events, and as recent stuff it only accepts UTF-8 input to start with and wont accept any cords right of column 95, which happens soon. If on sends \033[?1005h to xterm it reports all coords as UTF-8 making it straight forward. Please support that in future releases :-) (shouldn't be too difficult or?)
Created attachment 200847 [details] [review] Proposed patch Please see the proposed patch which implements the requested support. Note that the "DEC 1005" xterm extension mentioned Axel is broken by design. Why? See http://www.midnight-commander.org/ticket/2662 for a detailed explanation. Rxvt-unicode came up with a different, much better approach ("DEC 1015"). This patch supports both extensions. I made the patch against vte-0.26 because that's the most recent version I can compile with my glib/gtk, but it applies to the newest vte release, so I assume it works correctly on that too.
Thanks! The explanation on the mc ticket is most complete :-) (minus points for the ssl certificate problem, though). Given the brokenness of the xterm method, I'm inclined to think that vte should only add support for the fixed urxvt method.
Unfortunately I have no information on application support, e.g. there might be some apps that only support the xterm extension. So I really don't know what's the right behavior for terminals: whether to support such a bad extension (just in case an app still relies on them) or not (which gives a little push on apps to migrate to the good extension). IMHO it doesn't hurt, but I won't get offended if you throw out those bits from my patch :)
The patch itself looks mostly fine to me. Just two points: - I think the property should be unset on terminal reset - the property need to be initialised in vte_terminal_init
You're right, hang on for the next version.
Created attachment 200869 [details] [review] Proposed patch v2 Now I reset the two booleans at terminal reset. In vte_terminal_init() there's no sign of mouse initialization (not even the other mouse-related fields), seems to me that the data structure is memset() by zeros and then only the non-zero fields need to be initialized there, so I guess I'm fine with not touching that code. What's your take on this? I could explicitly zero out all the mouse-related fields. (And I'm wondering why init() doesn't include a reset()... nevermind.)
Comment on attachment 200869 [details] [review] Proposed patch v2 Committed to vte-0-32 branch with the broken xterm mode removed. Thanks again for the patch! I'm going to adapt the patch to vte-next and leave the bug open for that.
Fixed on vte-next (commit fa0b91a03291f7b989f759b8ed4cdfbc1b12e3f9).
Thanks!