From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: M-g in dired Date: Thu, 03 Nov 2005 09:48:54 +0200 Organization: JURTA Message-ID: <877jbqmrbc.fsf@jurta.org> References: <873bnf36mr.fsf@jurta.org> <878xwap86u.fsf@jurta.org> <8764rcye8k.fsf@jurta.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1131005924 30891 80.91.229.2 (3 Nov 2005 08:18:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 3 Nov 2005 08:18:44 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 03 09:18:43 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EXaHv-0003AQ-VW for ged-emacs-devel@m.gmane.org; Thu, 03 Nov 2005 09:17:36 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EXaHu-0001gr-P4 for ged-emacs-devel@m.gmane.org; Thu, 03 Nov 2005 03:17:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EXZyg-0006Es-Md for emacs-devel@gnu.org; Thu, 03 Nov 2005 02:57:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EXZyf-0006EN-I9 for emacs-devel@gnu.org; Thu, 03 Nov 2005 02:57:41 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EXZyf-0006EF-1q for emacs-devel@gnu.org; Thu, 03 Nov 2005 02:57:41 -0500 Original-Received: from [194.126.101.111] (helo=mail.neti.ee) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EXZye-00040U-3r; Thu, 03 Nov 2005 02:57:40 -0500 Original-Received: from mail.neti.ee (80-235-34-229-dsl.mus.estpak.ee [80.235.34.229]) by Relayhost1.neti.ee (Postfix) with ESMTP id 47E111A85; Thu, 3 Nov 2005 09:57:51 +0200 (EET) Original-To: rms@gnu.org In-Reply-To: (Richard M. Stallman's message of "Wed, 02 Nov 2005 05:27:21 -0500") User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-Virus-Scanned: by amavisd-new-2.2.1 (20041222) (Debian) at neti.ee 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:45342 Archived-At: > Since C-x is a valid prefix key, the value should not be 1. > It should be whatever the C-x subkeymap gives for `. This is true only for the global map, where "C-x `" is defined. So for the global map all is correct already: (lookup-key global-map "\C-x") => Control-X-prefix (lookup-key global-map "\C-x`") => next-error (lookup-key global-map "\C-x`abcdef") => 2 But in dired-mode-map, where "C-x `" is undefined, lookup-key currently returns: (lookup-key dired-mode-map "\C-x") => nil (lookup-key dired-mode-map "\C-x`") => 1 The return value `1' of the last expression seems wrong. The docstring of `lookup-key' says: A number as value means key is "too long"; that is, characters or symbols in it except for the last one fail to be a valid sequence of prefix characters in keymap. The number is how many characters at the front of key it takes to reach a non-prefix command. This docstring is not very clear. The documentation in the Emacs Lisp is better: If the string or vector KEY is not a valid key sequence according to the prefix keys specified in KEYMAP, it must be "too long" and have extra events at the end that do not fit into a single key sequence. Then the value is a number, the number of events at the front of KEY that compose a complete key. For the case of dired-mode-map where lookup-key returns 1 for "\C-x`", 1 is not a number of events at the front of "\C-x`" that compose a complete key, because "C-x" alone is not a valid key in dired-mode-map. My patch changes the return value from 1 to nil: (lookup-key dired-mode-map "\C-x`") => nil > Could you study the code some more to try to determine this? I have grepped the Emacs source tree, and almost everywhere the return value of lookup-key is checked for both nil and an integer in the same condition. There are only two functions where its return value is compared separately for an integer value: `emerge-force-define-key' and `emerge-define-key-if-possible' in lisp/emerge.el. They undefine the prefix key before redefining it with a longer key sequence. With my patch these functions will work right too. Currently they try to undefine key sequences that are not defined, but with my patch, they will not perform this useless operation. -- Juri Linkov http://www.jurta.org/emacs/