From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Guath Newsgroups: gmane.emacs.bugs Subject: bug#12868: global keymap preceeds input-decode-map Date: Mon, 12 Nov 2012 16:27:44 +0100 Message-ID: <1CEC3D0E-38C4-474F-B76C-BCA1BDC7E994@automata.se> References: <48A818DA-1AA9-4657-AC38-BE822EA18C65@automata.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1352734125 5375 80.91.229.3 (12 Nov 2012 15:28:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Nov 2012 15:28:45 +0000 (UTC) Cc: 12868@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 12 16:28: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 1TXvwU-0006pS-KL for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2012 16:28:54 +0100 Original-Received: from localhost ([::1]:36637 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXvwK-0006fp-JT for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 Nov 2012 10:28:44 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:43811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXvwG-0006bH-9W for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 10:28:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXvwD-0007kc-7M for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 10:28:40 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53559) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXvwD-0007kR-2c for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 10:28:37 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TXvwb-0003xO-Im for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 10:29:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Guath Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Nov 2012 15:29: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.135273409615138 (code B ref 12868); Mon, 12 Nov 2012 15:29:01 +0000 Original-Received: (at 12868) by debbugs.gnu.org; 12 Nov 2012 15:28:16 +0000 Original-Received: from localhost ([127.0.0.1]:35566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXvvr-0003w6-D9 for submit@debbugs.gnu.org; Mon, 12 Nov 2012 10:28:15 -0500 Original-Received: from mail-wi0-f180.google.com ([209.85.212.180]:62422) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXvvo-0003vx-Bj for 12868@debbugs.gnu.org; Mon, 12 Nov 2012 10:28:13 -0500 Original-Received: by mail-wi0-f180.google.com with SMTP id x18so204289wia.15 for <12868@debbugs.gnu.org>; Mon, 12 Nov 2012 07:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Oo1kdV5rvoqh+ZfPxJdGzDCo4Nr0n3rKknZZmOO9FyM=; b=rsAQf4FuqSMX/7fYEeT1lioXJQm5iYhAcDJUZPDEEn9mA0z03ZyccT4kFBfficoRl2 FwCP0HnnEiMdyKz1GxVQGSr3CfrrhWDNC/Tn63EABsOoojNxdomOtdhYKZ7WcV6MxGds do2bZCOUA+oRMgh0wshZtTOnSgSyEbpAEODVFVfeFAwPNS2rRQOWeu38cCwomU/liBgs Ynk4ScYHvQyfOs9Tj6nMuk1feBj88AzVnEENRFS34EumkgmT3QOZxQEr8DyeUoyG4B19 JjM26JURj8YB+CcxBKHkgaHAhDnDTdO74hfMnt+n4yvz4MnXqMl5R1k0VErA61uXWZFV dWhg== Original-Received: by 10.216.138.1 with SMTP id z1mr8361016wei.100.1352734066748; Mon, 12 Nov 2012 07:27:46 -0800 (PST) Original-Received: from [10.158.64.62] ([195.69.214.5]) by mx.google.com with ESMTPS id q10sm12135418wie.2.2012.11.12.07.27.44 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 07:27:45 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.1283) X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-Spam-Score: 0.1 (/) 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:66796 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"). 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. 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? 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? /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. >=20 > 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). >=20 > 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]. >=20 > 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. >=20 >=20 > Stefan