Re: Best way to intercept terminal escape sequences?

[Ryan Johnson]

 On 9/2/2010 12:53 PM, Stefan Monnier wrote:
> > 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.
> Handa, could you take a look at the feasibility of moving the
> decode_keyboard_code to a later stage such that read-event still returns
> raw bytes for ttys?
>
> There is a tension here, because raw events in GUIs are already decoded,
> whereas raw events in ttys are just bytes.  You "fixed it" by decoding
> tty input in directly in tty_read_avail_input, so that read-event now
> always returns decoded input, but that in turns means that read-event
> doesn't return raw events any more.  The decoding is desirable for
> read-key-sequence (and maybe also for read-char, tho I don't care much
> about this case since read-key is generally a better replacement) but
> not for read-event, since access to raw events is important for things
> like xt-mouse.el.
By the way, I noticed while working on something else [1] that read-key 
cannot actually replace all uses of read-event because the latter 
supports timeouts while the former does not. Would it be possible to add 
a timeout to read-key as a third (optional) parameter? I don't know 
whether read-key-delay would provide workarounds to some timeout uses, 
but it seems brittle.

> > 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.
> This doc is out of date, indeed.

It would be really nice to have, somewhere in the emacs docs, a diagram 
showing what processing happens to keyboard input, starting from raw 
bytes and UI events, and tracing them (or their translations) through 
coding systems, input methods, command loop, various keymaps, etc. and 
showing where in that process the different read-* functions intercept 
that data (and where the various unread-*-events reinsert things). A 
similar diagram for reading and writing files would probably also be useful.

This would not only make it easier to figure out how to interface new 
code with emacs, it would probably expose gaps in the API which make 
existing code unnecessarily complex and certain features impossible 
(mouse.el and xt-mouse.el suffer from both of those latter problems).

Unfortunately, even after spending so long on this problem I don't think 
I know enough to generate that diagram...

Ryan

[1] http://www.ece.cmu.edu/~ryanjohn/sticky-control.el