From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#12868: global keymap preceeds input-decode-map Date: Mon, 12 Nov 2012 12:03:04 -0500 Message-ID: References: <48A818DA-1AA9-4657-AC38-BE822EA18C65@automata.se> <1CEC3D0E-38C4-474F-B76C-BCA1BDC7E994@automata.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1352739825 27857 80.91.229.3 (12 Nov 2012 17:03:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Nov 2012 17:03:45 +0000 (UTC) Cc: 12868@debbugs.gnu.org To: Stefan Guath Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 12 18:03:55 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TXxQR-0002wK-1x for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2012 18:03:55 +0100 Original-Received: from localhost ([::1]:59346 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXxQG-0004Z3-VV for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2012 12:03:44 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXxQB-0004Xs-Ts for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 12:03:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXxQ8-0002aK-Rt for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 12:03:39 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXxQ8-0002aG-OK for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 12:03:36 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TXxQX-0006BK-If for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 12:04:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Nov 2012 17:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12868 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12868-submit@debbugs.gnu.org id=B12868.135273981323727 (code B ref 12868); Mon, 12 Nov 2012 17:04:01 +0000 Original-Received: (at 12868) by debbugs.gnu.org; 12 Nov 2012 17:03:33 +0000 Original-Received: from localhost ([127.0.0.1]:35762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXxQ4-0006Ad-RE for submit@debbugs.gnu.org; Mon, 12 Nov 2012 12:03:33 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:41516) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXxQ3-0006AU-2o for 12868@debbugs.gnu.org; Mon, 12 Nov 2012 12:03:31 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09sr+ZY/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0kiBwFugmLCIU8A4hCmnGBWIMH X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="207113850" Original-Received: from 108-175-230-88.dsl.teksavvy.com (HELO ceviche.home) ([108.175.230.88]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 12 Nov 2012 12:03:05 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 0CC9166389; Mon, 12 Nov 2012 12:03:05 -0500 (EST) In-Reply-To: <1CEC3D0E-38C4-474F-B76C-BCA1BDC7E994@automata.se> (Stefan Guath's message of "Mon, 12 Nov 2012 16:27:44 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-Spam-Score: 0.8 (/) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:66802 Archived-At: > I understand, and agree that a timeout is a bad idea. This should be > reflected in the manual though, just as it is for local-function-key-map > ("Entries in local-function-key-map are ignored if they conflict with > bindings made in the minor mode, local, or global keymaps"). I find it difficult to describe in a precise way without being too detailed, but I'll see what I can come up with. > Maybe it should also point out the consequences of binding escape > sequences used as prefix for common function keys, i.e. `ESC [' and > `ESC O'. One could even consider to unable colliding bindings to > emphasize that you have to choose, rather than 'bugging out' silently. Can you expand on what you mean by "unable colliding bindings". Do you mean that in your test case, Emacs should signal an error or at issue a warning, after seeing the M-O? Note that such colliding bindings already exist in the default config: "emacs -nw -Q" and then ESC ESC ESC will run keyboard-escape-quit even though the last ESC is a prefix of many function key escape sequences. > BTW, the manual states that "The intent of key-translation-map is for users > to map one character set to another, including ordinary characters normally > bound to self-insert-command." > Does this mean that key-translation-map is the recommended way to > implement different layouts such as Colemak/Dvorak etc at the lowest > possible level? No, I don't think so. But to tell you the truth, I do not know understand the reasoning behind key-translation-map. Also, I don't think there is a "recommended way" to provide such a remapping within Emacs, currently. Or rather than recommended way is probably to do the remapping outside of Emacs. > If yes, in the case of remapping `o' to `y' (Colemak example), M-O would > never get through the input-decode-map filter and therefore never pop up to > key-translation-map in order to produce M-Y. Is that correct? Yes, that's right. > /Stefan > On 12 nov 2012, at 15:32, Stefan Monnier wrote: >>> emacs -nw -Q >>> (defun foo () (interactive) (message "foo")) >>> (global-set-key "\M-O" 'foo) >> [...] >>> Arrow keys now inserts A,B,C,D in buffer. >> [...] >>> Arrow keys sends M-O A (up), M-O B (down) etc. These should be >>> translated to function keys , etc in input-decode-map >>> before any key lookup. Somehow, the binding of M-O in the global >>> keymap takes precedence. >> >> Indeed, thanks for bringing this up. The cause for the bug is that the >> rule for what goes first and what goes next is here ignored because we >> stop waiting for more input as soon as a real binding is found >> (i.e. right after M-O). >> >> The predicate that decides when to stop waiting for more input would >> need to say say "don't stop if we're in the middle of a potential >> input-decode-map rewrite". But then if you want to run `foo', you'd >> have the problem that after hitting M-O, Emacs will not actually run >> `foo' but will sit there waiting to see if the next key is one of >> [ABCD]. >> >> The only way to get our cake and eat it too would be to use some kind of >> timeout, which we have resisted so far. >> >> >> Stefan