Re: Best way to intercept terminal escape sequences?

[David Kastrup]

Ryan Johnson <address@hidden> writes:

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

You should set it to raw-text, do your mouse code preprocessing, and
afterwards decode the remainder using the intended coding system.

-- 
David Kastrup