Re: Best way to intercept terminal escape sequences?

[Ryan Johnson <ryanjohn@ece.cmu.edu>]

  On 8/28/2010 4:47 PM, Stefan Monnier wrote:
>> That might make sense... the caller could always apply the coding system
>> manually before dumping things back in the unread-command-events queue.
> Or coding-system decoding should be applied to events from
> unread-command-events.
That would basically be the proposed 'read-byte' behavior, then? Where 
read-char can filter out the raw inputs, and anything that it puts back 
goes through the whole input processing chain? Works for me!
>> 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.
Assuming this does get fixed, the xterm mouse events will be vastly more 
reliable.

Meanwhile, I've got a patch mostly ready which makes xt-mouse.el behave 
much more like native mouse. Xterm has a mode which sends mouse motion 
events whenever a button is down, and making mouse.el use read-key lets 
me send those events separately. The result is that clicking and 
dragging are highly responsive, where before you didn't see anything 
happen until after button release. The visual feedback is really helpful 
when dragging to highlight text.

I should also be able to add support for multi-click by emulating the 
behavior described in the elisp manual. I kind of hoped the emacs core 
would do that for me, given a stream of mouse-down and mouse-up events, 
but it doesn't. Oh well... some more code to write but nothing terrible. 
The only thing that would be missing is support for track-mouse and 
mouse-face, because they're hardwired in C.

It would be really nice if there were a way to hook into the native 
mouse subsystem rather than reinventing the wheel... it already computes 
what window/buffer a given coordinate is in, grabs timestamps, detects 
multi-click, and implements track-mouse/mouse-face. Assuming proper 
hooks were available, xterm does have a full mouse-tracking mode which 
we could use. That's way over my head to tackle, though.

Should I clean up the current patch, try to add multi-click, or see if 
somebody wants to expose some native mouse hooks?

Ryan