From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ryan Johnson Newsgroups: gmane.emacs.devel Subject: Re: Best way to intercept terminal escape sequences? Date: Sat, 28 Aug 2010 22:34:22 +0200 Message-ID: <4C7972CE.6070305@ece.cmu.edu> References: <20100827142724.E1DD712F@hazard.ece.cmu.edu> <4C77CF3C.6050406@ece.cmu.edu> <834oegm5c3.fsf@gnu.org> <4C78C0AF.5040502@ece.cmu.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1283027688 28298 80.91.229.12 (28 Aug 2010 20:34:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 28 Aug 2010 20:34:48 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 28 22:34:46 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OpS6w-0005zW-0K for ged-emacs-devel@m.gmane.org; Sat, 28 Aug 2010 22:34:46 +0200 Original-Received: from localhost ([127.0.0.1]:38571 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OpS6v-00028w-AR for ged-emacs-devel@m.gmane.org; Sat, 28 Aug 2010 16:34:45 -0400 Original-Received: from [140.186.70.92] (port=42448 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OpS6q-00028r-4z for emacs-devel@gnu.org; Sat, 28 Aug 2010 16:34:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OpS6o-0006TG-TV for emacs-devel@gnu.org; Sat, 28 Aug 2010 16:34:40 -0400 Original-Received: from bache.ece.cmu.edu ([128.2.129.23]:55903) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OpS6n-0006Ss-Ik; Sat, 28 Aug 2010 16:34:37 -0400 Original-Received: from [192.168.0.2] (145-122.76-83.cust.bluewin.ch [83.76.122.145]) by bache.ece.cmu.edu (Postfix) with ESMTP id 550FCC4; Sat, 28 Aug 2010 16:34:31 -0400 (EDT) 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 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Solaris 9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:129362 Archived-At: 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