Re: Best way to intercept terminal escape sequences?

[Ryan Johnson]

 On 8/27/2010 5:40 PM, Eli Zaretskii wrote:
> > Date: Fri, 27 Aug 2010 16:44:12 +0200
> > From: Ryan Johnson<address@hidden>
> >
> > Is there really no other way to do this?
> You could use the :post-read-conversion attribute of a coding-system.
> That is, define a new coding-system that has this attribute specifying
> a function you will write.  That function will first decode the mouse
> stuff, and then decode the rest by the terminal-coding-system set by
> the user.
> You can see an example of this in ctext-with-extensions.  It is
> defined on mule-conf.el and its post-read-conversion function is
> defined on mule.el.
That's actually what I tried first, but as I mentioned in the OP, emacs 
doesn't always deliver characters to :post-read-conversion in the 
correct order, which makes it impossible to do anything reliable with 
either escape sequences or utf-8. See 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6920 for more details.

The other problem is, I need to convert escape sequences into mouse 
events, not characters. Even if the bug were fixed, and even if it were 
easy to detect the user's desired coding system and piggy-back on it 
reliably, there's a problem with event ordering. I can't put a mouse 
event in the buffer, so if I'm ever given text and mouse-escape-sequence 
I'd have to leave the buffer empty, then load up unread-command-events 
with both text and mouse events. I'm not sure where those rejoin the 
input processing chain, but even with (t . EVT) I suspect they skip 
something (input methods, perhaps?). Also, I had some trouble getting (t 
. EVT) to work from within :post-read-conversion, though that could just 
be a bug in my code.

> Other than that, it's no surprise that this is not easy: we ask Emacs
> to read keyboard input that is encoded in two different encodings,
> which is not how keyboard input was designed.
Not quite... emacs insists on interpreting everything as encoded in some 
way, and I'd really like to just get my hands on a few raw bytes before 
it does so.

> I think the only way that is easier and cleaner would be if Emacs
> could read the mouse input from a separate file descriptor.  We could
> then set that file descriptor to use a different encoding.  Of course,
> that would need low-level changes in Emacs, even if it is possible in
> xterm.
What I had in mind was simpler:

Right now we have input -> coding system -> input method -> read-char -> 
input-decode-map -> ... other keymaps galore ... -> read-key

read-key is nice because it comes after all the interpretation is 
complete (high-level). Read-char is nice for interpreting key sequences 
(e.g. if you're a key map, mid-level), and it makes perfect sense to 
apply coding systems first. However, for things like escape sequences 
(very low-level), which are raw bytes with a specific meaning regardless 
of locale (and even keyboard layout, for xterm), coding systems are 
unnecessary at best and harmful at worst.

I'd propose adding an input filtering mechanism, which allows to 
register functions which pick off the raw input and are expected to put 
back anything they doesn't need. Sort of like a coding system, but 
orthogonal. Then you'd have:

input -> input-filter(s) -> coding system -> input method -> read-char 
-> input-decode-map -> ... other keymaps galore ... -> read-key

That said, if coding systems can really be abused as you suggest, and 
the ordering bug could be fixed, and unread-command-events does the 
right thing, then that would have the same effect and I'd be happy to 
use it. If just seems like taking the long way around.

Ryan