emacs-devel
[Top][All Lists]
Advanced

[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: Sat, 28 Aug 2010 22:34:22 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2

 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




reply via email to

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