Re: Best way to intercept terminal escape sequences?

[Ryan Johnson]

 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