From unknown Fri Aug 22 01:03:52 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#12868 <12868@debbugs.gnu.org> To: bug#12868 <12868@debbugs.gnu.org> Subject: Status: global keymap preceeds input-decode-map Reply-To: bug#12868 <12868@debbugs.gnu.org> Date: Fri, 22 Aug 2025 08:03:52 +0000 retitle 12868 global keymap preceeds input-decode-map reassign 12868 emacs submitter 12868 Stefan Guath severity 12868 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 12 04:07:20 2012 Received: (at submit) by debbugs.gnu.org; 12 Nov 2012 09:07:20 +0000 Received: from localhost ([127.0.0.1]:34627 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXpzD-0002oN-KM for submit@debbugs.gnu.org; Mon, 12 Nov 2012 04:07:20 -0500 Received: from eggs.gnu.org ([208.118.235.92]:48336) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXpzA-0002oE-MF for submit@debbugs.gnu.org; Mon, 12 Nov 2012 04:07:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXpyk-0000kr-7Z for submit@debbugs.gnu.org; Mon, 12 Nov 2012 04:06:53 -0500 Received: from lists.gnu.org ([208.118.235.17]:60561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXpyk-0000kn-3Z for submit@debbugs.gnu.org; Mon, 12 Nov 2012 04:06:50 -0500 Received: from eggs.gnu.org ([208.118.235.92]:54203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXpyh-0008Eg-0H for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 04:06:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXpyd-0000il-UG for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 04:06:46 -0500 Received: from mail-la0-f41.google.com ([209.85.215.41]:52755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXpyd-0000iQ-L6 for bug-gnu-emacs@gnu.org; Mon, 12 Nov 2012 04:06:43 -0500 Received: by mail-la0-f41.google.com with SMTP id p5so5005438lag.0 for ; Mon, 12 Nov 2012 01:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=DWw5iBH7354q1Z3I61W7PsyE5Ate5zVbbujqPzuO5JI=; b=YONJgMASif51zxL5QYrrmzuR9n2+WPzVXwcLPfFMM6L+L5E44j8NMHZL+KobD/rjtQ Bz+J3XJTLzUeGpodRKvUjZ8ds3VhsHMuNxcrAbLkW+k5ijp/7SGfYvqf3dvxcniNGGki IbAsAFJWsWrlZD+q3FNm0NVPNB79oW6vCto440NgxT1V55y7iLt6n7LtyzuVtGHmRNKk dWNwH54qaTf5QAV09YforQvGPOAfR06VZnv7kstrHFb8LiDQgVRKFXmN9lgiGRhCL5LQ 0OyzTy9O4ogZxiDg/u11rdDiKfSJypNGeqLXQGBIaPMXGVLBmmuzjrwk+gCNpBgnatLs y/IQ== Received: by 10.152.106.171 with SMTP id gv11mr17803932lab.26.1352711202160; Mon, 12 Nov 2012 01:06:42 -0800 (PST) Received: from [192.168.1.2] (m37-2-170-123.cust.tele2.se. [37.2.170.123]) by mx.google.com with ESMTPS id pz9sm2181362lab.11.2012.11.12.01.06.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 01:06:41 -0800 (PST) From: Stefan Guath Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: global keymap preceeds input-decode-map Date: Mon, 12 Nov 2012 10:06:38 +0100 Message-Id: <48A818DA-1AA9-4657-AC38-BE822EA18C65@automata.se> To: bug-gnu-emacs@gnu.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) emacs-version: GNU Emacs 24.2.1 (x86_64-apple-darwin, NS = apple-appkit-1038.36) of 2012-08-27 on bob.porkrind.org To trigger bug: emacs -nw -Q (defun foo () (interactive) (message "foo")) (global-set-key "\M-O" 'foo) Bug symptons: Arrow keys now inserts A,B,C,D in buffer. Suggested bug reason: 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. This would be expected with local-function-key-map as = described in = http://www.gnu.org/software/emacs/manual/html_node/elisp/Translation-Keyma= ps.html , but not with input-decode-map. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 12 09:33:03 2012 Received: (at 12868) by debbugs.gnu.org; 12 Nov 2012 14:33:03 +0000 Received: from localhost ([127.0.0.1]:35146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXv4P-0002bh-Nk for submit@debbugs.gnu.org; Mon, 12 Nov 2012 09:33:03 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:20147) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXv4J-0002bU-9f for 12868@debbugs.gnu.org; Mon, 12 Nov 2012 09:32:55 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09sr+ZY/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0kiBwFugmQRAOIQppxgViDBw X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="206970408" Received: from 108-175-230-88.dsl.teksavvy.com (HELO pastel.home) ([108.175.230.88]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 12 Nov 2012 09:32:30 -0500 Received: by pastel.home (Postfix, from userid 20848) id 8278A5978D; Mon, 12 Nov 2012 09:32:29 -0500 (EST) From: Stefan Monnier To: Stefan Guath Subject: Re: bug#12868: global keymap preceeds input-decode-map Message-ID: References: <48A818DA-1AA9-4657-AC38-BE822EA18C65@automata.se> Date: Mon, 12 Nov 2012 09:32:29 -0500 In-Reply-To: <48A818DA-1AA9-4657-AC38-BE822EA18C65@automata.se> (Stefan Guath's message of "Mon, 12 Nov 2012 10:06:38 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 12868 Cc: 12868@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) > 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 12 10:28:16 2012 Received: (at 12868) by debbugs.gnu.org; 12 Nov 2012 15:28:16 +0000 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 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 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== Received: by 10.216.138.1 with SMTP id z1mr8361016wei.100.1352734066748; Mon, 12 Nov 2012 07:27:46 -0800 (PST) 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) Subject: Re: bug#12868: global keymap preceeds input-decode-map Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Stefan Guath In-Reply-To: Date: Mon, 12 Nov 2012 16:27:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1CEC3D0E-38C4-474F-B76C-BCA1BDC7E994@automata.se> References: <48A818DA-1AA9-4657-AC38-BE822EA18C65@automata.se> To: Stefan Monnier X-Mailer: Apple Mail (2.1283) X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12868 Cc: 12868@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 12 12:03:33 2012 Received: (at 12868) by debbugs.gnu.org; 12 Nov 2012 17:03:33 +0000 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 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" 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 Received: by ceviche.home (Postfix, from userid 20848) id 0CC9166389; Mon, 12 Nov 2012 12:03:05 -0500 (EST) From: Stefan Monnier To: Stefan Guath Subject: Re: bug#12868: global keymap preceeds input-decode-map Message-ID: References: <48A818DA-1AA9-4657-AC38-BE822EA18C65@automata.se> <1CEC3D0E-38C4-474F-B76C-BCA1BDC7E994@automata.se> Date: Mon, 12 Nov 2012 12:03:04 -0500 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) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 12868 Cc: 12868@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) > 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 12 12:32:18 2012 Received: (at 12868) by debbugs.gnu.org; 12 Nov 2012 17:32:18 +0000 Received: from localhost ([127.0.0.1]:35816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXxrt-0006pM-JV for submit@debbugs.gnu.org; Mon, 12 Nov 2012 12:32:18 -0500 Received: from mail-wi0-f180.google.com ([209.85.212.180]:45654) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TXxrq-0006pD-LV for 12868@debbugs.gnu.org; Mon, 12 Nov 2012 12:32:16 -0500 Received: by mail-wi0-f180.google.com with SMTP id x18so317159wia.15 for <12868@debbugs.gnu.org>; Mon, 12 Nov 2012 09:31:48 -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=Mwd8h0YtPqIHnV5OdlVu+/JXd0GQFwSpKhenC2ry94A=; b=YOP9FkCU/4yhMz6yh+ksdk+kg7G6KcydjjI7dKiTMfPIRjEbrBwlhJHVyaesc3hGrO 2tHKq7dLBZSRclzP+ObkWAj1biQFDLBBRlmFf6/MwWQ2iVT7YLDFaIm17339bTaqHfQD r8JhZabH9TxDdXlbVkpXbzdL6TteK+3HEPqfnoBgxT66nyizG19u+75Y5Y2eDpXOkK46 +PgB2Udth9m1bp+5sXufK2L9FaXC57vfyHoAjMlD0EdPzzhdVkN971gX2LBQMb64Arvr faK+Bj+w9foJ351Tg20e/qUu6zNRcQ3ksCWNp10+BzVj5PIjNQELUk1Fh5RgnV/bG7dJ X21w== Received: by 10.216.134.85 with SMTP id r63mr7537824wei.150.1352741508508; Mon, 12 Nov 2012 09:31:48 -0800 (PST) Received: from [10.158.64.62] ([195.69.214.5]) by mx.google.com with ESMTPS id fa9sm12599460wib.5.2012.11.12.09.31.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 09:31:47 -0800 (PST) Subject: Re: bug#12868: global keymap preceeds input-decode-map Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Stefan Guath In-Reply-To: Date: Mon, 12 Nov 2012 18:31:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <48A818DA-1AA9-4657-AC38-BE822EA18C65@automata.se> <1CEC3D0E-38C4-474F-B76C-BCA1BDC7E994@automata.se> To: Stefan Monnier X-Mailer: Apple Mail (2.1283) X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12868 Cc: 12868@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) On 12 nov 2012, at 18:03, Stefan Monnier wrote: >> 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"). >=20 > I find it difficult to describe in a precise way without being > too detailed, but I'll see what I can come up with. The input-decode-map section could just have the exact same sentence as = local-function-key-map has, i.e. "Entries in input-decode-map are = ignored if they conflict with bindings made in the minor mode, local, or = global keymaps". Since local-function-key-map has that sentence, and = input-decode-map does not, one assume that they work differently. Which = is not the case. The key-translation-map section is plain out wrong: "Just like = input-decode-map, but unlike local-function-key-map, this keymap is = applied regardless of whether the input key-sequence has a normal = binding." No, input-decode-map nor key-translation-map has precedence = over normal bindings - it's just the other way around. >> 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. >=20 > 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? >=20 > 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. Yes, that was sort of what I meant, but I agree it was a bad idea. But = the manual could at least conclude the entire section 22.14 with a = reminder that since normal bindings do have precedence over all three of = input-decode-map, local-function-key-map and key-translation-map, it's a = bad idea to bind anything that collides with them such as `ESC O' or = `ESC ['. People don't have to understand why - just prevent them from = binding M-O and M-[. >> 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? >=20 > No, I don't think so. But to tell you the truth, I do not know > understand the reasoning behind key-translation-map. Me neither... It's confusing... > 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. Thanks! I've struggled with this and always thought that I missed = something obvious. >> 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? >=20 > Yes, that's right. Great - I thought I'd misunderstood something fundamental. Thanks for = all the clarifications! From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 12 16:08:15 2012 Received: (at 12868) by debbugs.gnu.org; 12 Nov 2012 21:08:15 +0000 Received: from localhost ([127.0.0.1]:36225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TY1Et-00057O-Eh for submit@debbugs.gnu.org; Mon, 12 Nov 2012 16:08:15 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:44062) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TY1Er-00057F-FM for 12868@debbugs.gnu.org; Mon, 12 Nov 2012 16:08:13 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09sr+ZY/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0kiBwFugmQRAOIQppxgViDBw X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="207195986" Received: from 108-175-230-88.dsl.teksavvy.com (HELO pastel.home) ([108.175.230.88]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 12 Nov 2012 16:07:47 -0500 Received: by pastel.home (Postfix, from userid 20848) id AF9E9592BD; Mon, 12 Nov 2012 16:07:46 -0500 (EST) From: Stefan Monnier To: Stefan Guath Subject: Re: bug#12868: global keymap preceeds input-decode-map Message-ID: References: <48A818DA-1AA9-4657-AC38-BE822EA18C65@automata.se> <1CEC3D0E-38C4-474F-B76C-BCA1BDC7E994@automata.se> Date: Mon, 12 Nov 2012 16:07:46 -0500 In-Reply-To: (Stefan Guath's message of "Mon, 12 Nov 2012 18:31:48 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 12868 Cc: 12868@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.8 (/) > The input-decode-map section could just have the exact same sentence as > local-function-key-map has, i.e. "Entries in input-decode-map are ignored if > they conflict with bindings made in the minor mode, local, or global > keymaps". Since local-function-key-map has that sentence, and > input-decode-map does not, one assume that they work differently. Which is > not the case. But they do work differently: If you have a global-map binding of "M-O A", the input-decode-map remapping will take precedence, whereas a function-key-map remapping would be ignored. It's a tricky business. > Yes, that was sort of what I meant, but I agree it was a bad idea. I don't think it's a bad idea, but it seems difficult to come up with a way to detect actual problematic cases and brings them to the user's attention (without being annoying, that is). The best moment to detect those problem is when the global map is modified, but the functions that are involved are the same as for input-decode-map ;-) > But the manual could at least conclude the entire section 22.14 with > a reminder that since normal bindings do have precedence over all > three of input-decode-map, local-function-key-map and > key-translation-map, it's a bad idea to bind anything that collides > with them such as `ESC O' or `ESC ['. People don't have to understand > why - just prevent them from binding M-O and M-[. Sounds right. I'll see about doing that. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 15 09:17:48 2012 Received: (at 12868-done) by debbugs.gnu.org; 15 Nov 2012 14:17:48 +0000 Received: from localhost ([127.0.0.1]:44589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZ0GJ-0006t1-E6 for submit@debbugs.gnu.org; Thu, 15 Nov 2012 09:17:47 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:44859) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TZ0GG-0006st-OV for 12868-done@debbugs.gnu.org; Thu, 15 Nov 2012 09:17:45 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09sr+ZY/2dsb2JhbABEtBGBCIIWAQVWHgUQCzQSFBgNJBOIAAMLugmQRAOIQppxgViDBw X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="207675126" Received: from 108-175-230-88.dsl.teksavvy.com (HELO pastel.home) ([108.175.230.88]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 15 Nov 2012 09:17:02 -0500 Received: by pastel.home (Postfix, from userid 20848) id 10A41594C8; Thu, 15 Nov 2012 09:17:01 -0500 (EST) From: Stefan Monnier To: Stefan Guath Subject: Re: bug#12868: global keymap preceeds input-decode-map Message-ID: References: <48A818DA-1AA9-4657-AC38-BE822EA18C65@automata.se> <1CEC3D0E-38C4-474F-B76C-BCA1BDC7E994@automata.se> Date: Thu, 15 Nov 2012 09:17:01 -0500 In-Reply-To: (Stefan Monnier's message of "Mon, 12 Nov 2012 16:07:46 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 12868-done Cc: 12868-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) I've installed the patch below to try and better explain what's going on and warn about possible problems. Stefan === modified file 'doc/lispref/ChangeLog' --- doc/lispref/ChangeLog 2012-11-15 05:25:05 +0000 +++ doc/lispref/ChangeLog 2012-11-15 14:15:36 +0000 @@ -1,3 +1,8 @@ +2012-11-15 Stefan Monnier + + * keymaps.texi (Translation Keymaps): Add a subsection "Interaction + with normal keymaps". + 2012-11-15 Dmitry Antipov * internals.texi (Garbage Collection): Update descriptions === modified file 'doc/lispref/keymaps.texi' --- doc/lispref/keymaps.texi 2012-10-28 14:56:51 +0000 +++ doc/lispref/keymaps.texi 2012-11-15 14:12:01 +0000 @@ -1540,14 +1540,11 @@ being read, as it is read, against @code{input-decode-map}, then @code{local-function-key-map}, and then against @code{key-translation-map}. -@defvar input-decode-map -This variable holds a keymap that describes the character sequences sent -by function keys on an ordinary character terminal. This keymap has the -same structure as other keymaps, but is used differently: it specifies -translations to make while reading key sequences, rather than bindings -for key sequences. +These keymaps have the same structure as other keymaps, but they are used +differently: they specify translations to make while reading key sequences, +rather than bindings for key sequences. -If @code{input-decode-map} ``binds'' a key sequence @var{k} to a vector +If one of these keymaps ``binds'' a key sequence @var{k} to a vector @var{v}, then when @var{k} appears as a subsequence @emph{anywhere} in a key sequence, it is replaced with the events in @var{v}. @@ -1562,6 +1559,10 @@ this back into @kbd{C-c @key{PF1}}, which it returns as the vector @code{[?\C-c pf1]}. +@defvar input-decode-map +This variable holds a keymap that describes the character sequences sent +by function keys on an ordinary character terminal. + The value of @code{input-decode-map} is usually set up automatically according to the terminal's Terminfo or Termcap entry, but sometimes those need help from terminal-specific Lisp files. Emacs comes with @@ -1636,8 +1637,6 @@ (let ((symbol (if (symbolp e) e (car e)))) (setq symbol (intern (concat string (symbol-name symbol)))) -@end group -@group (if (symbolp e) symbol (cons symbol (cdr e))))) @@ -1647,10 +1646,30 @@ @end example If you have enabled keyboard character set decoding using -@code{set-keyboard-coding-system}, decoding is done after the -translations listed above. @xref{Terminal I/O Encoding}. However, in -future Emacs versions, character set decoding may be done at an -earlier stage. +@code{set-keyboard-coding-system}, decoding is done before the +translations listed above. @xref{Terminal I/O Encoding}. + +@subsection Interaction with normal keymaps + +The end of a key sequence is detected when that key sequence either is bound +to a command, or when Emacs determines that no additional event can lead +to a sequence that is bound to a command. + +This means that, while @code{input-decode-map} and @code{key-translation-map} +apply regardless of whether the original key sequence would have a binding, the +presence of such a binding can still prevent translation from taking place. +For example, let us return to our VT100 example above and add a binding for +@kbd{C-c @key{ESC}} to the global map; now when the user hits @kbd{C-c +@key{PF1}} Emacs will fail to decode @kbd{C-c @key{ESC} O P} into @kbd{C-c +@key{PF1}} because it will stop reading keys right after @kbd{C-x @key{ESC}}, +leaving @kbd{O P} for later. This is in case the user really hit @kbd{C-c +@key{ESC}}, in which case Emacs should not sit there waiting for the next key +to decide whether the user really pressed @kbd{@key{ESC}} or @kbd{@key{PF1}}. + +For that reason, it is better to avoid binding commands to key sequences where +the end of the key sequence is a prefix of a key translation. The main such +problematic suffixes/prefixes are @kbd{@key{ESC}}, @kbd{M-O} (which is really +@kbd{@key{ESC} O}) and @kbd{M-[} (which is really @kbd{@key{ESC} [}). @node Key Binding Commands @section Commands for Binding Keys From unknown Fri Aug 22 01:03:52 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 14 Dec 2012 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator