Re: Best way to intercept terminal escape sequences?

[Ryan Johnson]

 On 8/28/2010 4:47 PM, Stefan Monnier wrote:
> > Who currently uses read-* that might be affected? xt-mouse.el would love it,
> > mouse.el certainly won't care, and other xterm processing will
> > be indifferent.
> As mentioned, read-event did not do obey keyboard-coding-system in
> earlier Emacsen, so any affected package is more likely to be fixed than
> broken by making a change that reverts to this previous behavior.
Hmm... here's a twist: The elisp docs under keymaps -> translation 
keymaps explain that:

If you have enabled keyboard character set decoding using
`set-keyboard-coding-system', decoding is done after the translations
listed above.  See Terminal I/O Encoding.  However, in future Emacs
versions, character set decoding may be done at an earlier stage.

However, the same info node admits that translation keymaps may want to 
read input (which does *not* escape I/O coding). So, suppose we do the 
following:

(define-key
  input-decode-map
  "\M-[M"; CSI M
  '(keymap; pb
    (t keymap; px
       (t keymap; py
          (t . xterm-mouse-translate)))))

In theory, the above matches any three characters following the start of 
the mouse escape sequence. Then inside xterm-mouse-translate 
(this-command-keys) comes close to being raw bytes. It now works great 
for any px I can throw at it, but still something goes wrong for py > #x7f.

If I print (this-command-keys-vector) after a mouse click at (0 . 95), I 
get: [27 91 77 32 33 4194176] -- mouse-down -- and then emacs hangs 
waiting for more input; the next key I type ends up prefixed by \200.  
The lossage buffer shows ESC [ M SPC ! \300\200 ESC [ M # ! \300\200, 
but I don't know where the 'ESC [ M # ! \300' part disappeared to -- it 
doesn't get inserted into any buffer and yet xterm-mouse-translate never 
gets called, either.

The docs seem out of date about where coding systems kick in... 
apparently it still tries to decode utf-8 somehow, even though I never 
call read-*.

Even if I (set-keyboard-coding-system 'no-conversion), the bytes turn 
into all kinds of strange M- and C- versions of characters, which is no 
fun to disentangle. 'raw-text and 'binary give different but equally 
not-fun sets of weirdness.

I'm beginning to think there's actually no way to get raw bytes from the 
terminal...

Ideas?
Ryan