[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best way to intercept terminal escape sequences?

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: 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).


*** 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).

Attachment: xt-mouse.el.utf-8.patch
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]