Re: Best way to intercept terminal escape sequences?

[Eli Zaretskii]

> Date: Fri, 27 Aug 2010 20:04:48 +0200
> From: Ryan Johnson <address@hidden>
> CC: address@hidden
> 
>   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.

You need to base your system on raw-text or no-conversion.  Then the
bytes will arrive unscathed.

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

Well, mouse events aren't supposed to arrive by way of keyboard input,
either, you know.  They are supposed to come from a totally different
API.