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: Thu, 02 Sep 2010 14:33:36 +0200 Message-ID: <4C7F99A0.4090502@ece.cmu.edu> 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1283430846 32284 80.91.229.12 (2 Sep 2010 12:34:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Sep 2010 12:34:06 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, Kenichi Handa To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 02 14:34:00 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 1Or8zP-0004cQ-H8 for ged-emacs-devel@m.gmane.org; Thu, 02 Sep 2010 14:33:59 +0200 Original-Received: from localhost ([127.0.0.1]:35575 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Or8zM-0002Gd-EE for ged-emacs-devel@m.gmane.org; Thu, 02 Sep 2010 08:33:56 -0400 Original-Received: from [140.186.70.92] (port=60238 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Or8zF-0002GY-6b for emacs-devel@gnu.org; Thu, 02 Sep 2010 08:33:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Or8zE-0005j0-1O for emacs-devel@gnu.org; Thu, 02 Sep 2010 08:33:49 -0400 Original-Received: from bache.ece.cmu.edu ([128.2.129.23]:40224) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Or8zC-0005iP-Oz; Thu, 02 Sep 2010 08:33:46 -0400 Original-Received: from [128.178.77.144] (diaspc12.epfl.ch [128.178.77.144]) by bache.ece.cmu.edu (Postfix) with ESMTP id 60B9A99; Thu, 2 Sep 2010 08:33:39 -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:129586 Archived-At: On 9/2/2010 12:53 PM, Stefan Monnier wrote: >> 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. By the way, I noticed while working on something else [1] that read-key cannot actually replace all uses of read-event because the latter supports timeouts while the former does not. Would it be possible to add a timeout to read-key as a third (optional) parameter? I don't know whether read-key-delay would provide workarounds to some timeout uses, but it seems brittle. >> 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. It would be really nice to have, somewhere in the emacs docs, a diagram showing what processing happens to keyboard input, starting from raw bytes and UI events, and tracing them (or their translations) through coding systems, input methods, command loop, various keymaps, etc. and showing where in that process the different read-* functions intercept that data (and where the various unread-*-events reinsert things). A similar diagram for reading and writing files would probably also be useful. This would not only make it easier to figure out how to interface new code with emacs, it would probably expose gaps in the API which make existing code unnecessarily complex and certain features impossible (mouse.el and xt-mouse.el suffer from both of those latter problems). Unfortunately, even after spending so long on this problem I don't think I know enough to generate that diagram... Ryan [1] http://www.ece.cmu.edu/~ryanjohn/sticky-control.el