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: Fri, 04 Nov 2005 14:06:09 +0200 Organization: JURTA Message-ID: <87zmok96ry.fsf@jurta.org> References: <873bnf36mr.fsf@jurta.org> <878xwap86u.fsf@jurta.org> <8764rcye8k.fsf@jurta.org> <877jbqmrbc.fsf@jurta.org> <87r79xzsl5.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1131106971 6876 80.91.229.2 (4 Nov 2005 12:22:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 4 Nov 2005 12:22:51 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 04 13:22:40 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EY0ac-0005wh-Px for ged-emacs-devel@m.gmane.org; Fri, 04 Nov 2005 13:22:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EY0ac-0005js-58 for ged-emacs-devel@m.gmane.org; Fri, 04 Nov 2005 07:22:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EY0a0-0005Vm-VE for emacs-devel@gnu.org; Fri, 04 Nov 2005 07:22:01 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EY0Zz-0005VH-3K for emacs-devel@gnu.org; Fri, 04 Nov 2005 07:22:00 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EY0Zy-0005VC-S6 for emacs-devel@gnu.org; Fri, 04 Nov 2005 07:21:58 -0500 Original-Received: from [194.126.101.111] (helo=mail.neti.ee) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EY0Zx-0001Nq-T3; Fri, 04 Nov 2005 07:21:58 -0500 Original-Received: from mail.neti.ee (80-235-32-157-dsl.mus.estpak.ee [80.235.32.157]) by Relayhost1.neti.ee (Postfix) with ESMTP id 5958AC5D2; Fri, 4 Nov 2005 14:22:07 +0200 (EET) Original-To: Stefan Monnier In-Reply-To: <87r79xzsl5.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Thu, 03 Nov 2005 10:03:18 -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:45391 Archived-At: >> 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. > > It doesn't say "valid key" it says "valid key sequence". "C-x" is a valid > key sequence in this context. It is not bound to anything, but it is > a valid sequence. C-x ` is not a valid sequence on the other hand, because > read-key-sequence would have immediately stopped after C-x. >>From the docstring I understood that "valid key sequence" means a valid and bound key sequence, due to the sentence: The number is how many characters at the front of key it takes to reach a non-prefix command. To me "a non-prefix command" implies a bound command key sequence. That's why I changed the code to return the integer value only on the condition `if (!NILP (cmd))'. However, if this is not what the docstring meant, and leaving the logic of the current return value is desirable, then maybe `lookup-key' needs an additional argument defining another logic of its return value. Otherwise, almost all code in `lookup-key' should be duplicated in `shadow_lookup'. -- Juri Linkov http://www.jurta.org/emacs/