|
From: | Ryan Johnson |
Subject: | Re: Best way to intercept terminal escape sequences? |
Date: | Fri, 27 Aug 2010 11:28:21 +0200 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 |
On 8/27/2010 1:03 AM, Stefan Monnier wrote:
all encoded events of some sort. For example, the xterm escape sequence "ESC O D" is eventually converted to<right>, but anybody calling read-char or read-event will get a string of characters instead (and probably wish they hadn't).Yes, that's why they should use `read-key' instead.
!!I didn't know about that function. I tried s/read-event/read-char/ in mouse.el, and nothing obvious broke. However, I'll need to modify xt-mouse.el to take advantage of the change -- it still doesn't trust mouse.el.
Meanwhile, though, I'm hitting another problem which still seems to require a lower-than-low-level equivalent for read-char which can bypass coding systems.
For reasons I don't understand, xterm's mouse escape sequence is completely non-standard: "ESC [ M pb px py". The p* are bytes taking values between 33 and 255, and there is no terminator byte.***
The result of this unfortunate design decision is that px and py can throw a huge wrench in emacs' utf-8 decoding, because a (px py) pair can look like all kinds of utf-8 (valid or otherwise). As long as px < 0xe0 *and* py< 0xC0 I can reliably decompose the unicode char I'm given into the original utf-8 sequence (possibly in the illegal C0 or C1 range) and py follows immediately to satisfy the decoder. The rest of the time, though, the lack of a sequence terminator leaves me at the decoder's mercy to decide how to interpret the bytes, and it's at the mercy of whatever input follows the mouse sequence.
I tried setting the keyboard-coding-system to iso-latin-1, but no luck.For down-mouse and move-mouse, things works out all right. A mouse-up or mouse-move always follows and the leading ESC makes emacs give up and hand over the raw bytes. The up-mouse sequence, though, doesn't usually have anything after it, so emacs waits patiently for more input. Clicking at position (184 . 136), for example, leaves the minibuffer prompt: "ESC [ M SPC \300\270 \300\210 ESC [ M #-". Fortunately, ^G works as expected, so it's merely annoying. This is a huge improvement over the current practice of dumping a bunch of garbage bytes into the user's buffer, so I'm attaching a preliminary patch (against the emacs-23.2 release, btw).
Thoughts? Ryan*** It *really* should have been something like "ESC [ M pb ; px ; py m" with the p* being string representations of integers. I'm discussing possible fixes with the xterm maintainer, but it could be a while (and would require creating a new mouse mode to avoid breaking existing apps).
xt-mouse.el.utf-8.patch
Description: Text document
[Prev in Thread] | Current Thread | [Next in Thread] |