From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Best way to intercept terminal escape sequences? Date: Thu, 02 Sep 2010 12:53:52 +0200 Message-ID: References: <20100827142724.E1DD712F@hazard.ece.cmu.edu> <4C77CF3C.6050406@ece.cmu.edu> <834oegm5c3.fsf@gnu.org> <4C78C0AF.5040502@ece.cmu.edu> <4C7D8C45.8060500@ece.cmu.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1283426135 10921 80.91.229.12 (2 Sep 2010 11:15:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Sep 2010 11:15:35 +0000 (UTC) Cc: Eli Zaretskii , Ryan Johnson , emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 02 13:15:32 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 1Or7lQ-0006lp-6O for ged-emacs-devel@m.gmane.org; Thu, 02 Sep 2010 13:15:32 +0200 Original-Received: from localhost ([127.0.0.1]:60920 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Or7lM-0002Jf-Li for ged-emacs-devel@m.gmane.org; Thu, 02 Sep 2010 07:15:24 -0400 Original-Received: from [140.186.70.92] (port=59680 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Or7ZQ-0007Ax-RP for emacs-devel@gnu.org; Thu, 02 Sep 2010 07:03:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Or7Qg-0002YO-FS for emacs-devel@gnu.org; Thu, 02 Sep 2010 06:54:03 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:56395) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Or7Qg-0002YB-98; Thu, 02 Sep 2010 06:54:02 -0400 Original-Received: from ceviche.home (vpn-132-204-232-35.acd.umontreal.ca [132.204.232.35]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o82Artvd028706; Thu, 2 Sep 2010 06:53:55 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 0C2EE660DF; Thu, 2 Sep 2010 12:53:53 +0200 (CEST) In-Reply-To: <4C7D8C45.8060500@ece.cmu.edu> (Ryan Johnson's message of "Wed, 01 Sep 2010 01:12:05 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3613=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:129580 Archived-At: > 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. Handa, could you take a look at the feasibility of moving the decode_keyboard_code to a later stage such that read-event still returns raw bytes for ttys? There is a tension here, because raw events in GUIs are already decoded, whereas raw events in ttys are just bytes. You "fixed it" by decoding tty input in directly in tty_read_avail_input, so that read-event now always returns decoded input, but that in turns means that read-event doesn't return raw events any more. The decoding is desirable for read-key-sequence (and maybe also for read-char, tho I don't care much about this case since read-key is generally a better replacement) but not for read-event, since access to raw events is important for things like xt-mouse.el. > Hmm... here's a twist: The elisp docs under keymaps -> translation keymaps > explain that: > If you have enabled keyboard character set decoding using > `set-keyboard-coding-system', decoding is done after the translations > listed above. See Terminal I/O Encoding. However, in future Emacs > versions, character set decoding may be done at an earlier stage. This doc is out of date, indeed. Stefan