[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: Wed, 01 Sep 2010 01:12:05 +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/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:

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


reply via email to

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