[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: Fri, 27 Aug 2010 20:04:48 +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/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
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.


reply via email to

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