unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@jurta.org>
Cc: emacs-devel@gnu.org
Subject: Re: M-g in dired
Date: Thu, 03 Nov 2005 09:48:54 +0200	[thread overview]
Message-ID: <877jbqmrbc.fsf@jurta.org> (raw)
In-Reply-To: <E1EXFpx-0001DZ-7V@fencepost.gnu.org> (Richard M. Stallman's message of "Wed, 02 Nov 2005 05:27:21 -0500")

> 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/

  reply	other threads:[~2005-11-03  7:48 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-15 11:27 M-g in dired Juri Linkov
2005-10-15 19:33 ` Kim F. Storm
2005-10-16 14:40 ` Richard M. Stallman
2005-10-16 14:40 ` Richard M. Stallman
2005-10-31  1:14 ` Richard Stallman
2005-10-31  7:47   ` Juri Linkov
2005-11-01  2:13     ` Richard M. Stallman
2005-11-01  9:16       ` Juri Linkov
2005-11-01 14:09         ` Andreas Schwab
2005-11-01 19:55           ` Juri Linkov
2005-11-02 10:28             ` Richard M. Stallman
2005-11-02 10:27         ` Richard M. Stallman
2005-11-03  7:48           ` Juri Linkov [this message]
2005-11-03 15:03             ` Stefan Monnier
2005-11-04 12:06               ` Juri Linkov
2005-11-05  1:37                 ` Richard M. Stallman
2005-11-05  7:55                   ` Juri Linkov
2005-11-05 23:43                     ` Richard M. Stallman
2005-11-07 14:27                       ` Juri Linkov
2005-11-07 16:03                         ` Stefan Monnier
2005-11-08 12:43                           ` Juri Linkov
2005-11-09  2:57                             ` Richard M. Stallman
2005-11-07 21:56                         ` Richard M. Stallman
2005-11-03 21:41             ` Richard M. Stallman
     [not found] <446C7B73.60907@earthlink.net>
2006-05-19  2:04 ` Richard Stallman
2006-05-19  3:04   ` Juri Linkov
2006-05-19  8:16     ` Kim F. Storm
2006-05-19  8:43       ` Miles Bader
2006-05-19 12:37         ` Kim F. Storm
2006-05-20 13:45         ` Juri Linkov
2006-05-20  5:03       ` Richard Stallman
     [not found]     ` <E1FhJd4-000822-Fe@fencepost.gnu.org>
2006-05-20 13:45       ` Juri Linkov
2006-05-20 15:46         ` Johan Bockgård
2006-05-20 20:03           ` Juri Linkov
2006-05-20 20:41             ` Romain Francoise
2006-05-21  0:56         ` Richard Stallman
2006-05-21  4:28           ` Juri Linkov
2006-05-22  2:38             ` Richard Stallman
2006-05-22 13:46               ` Juri Linkov
2006-05-22 20:37                 ` Richard Stallman
2006-05-23  5:16                   ` Juri Linkov
2006-05-19 18:53   ` David Hansen
2006-05-19 19:57     ` Reiner Steib
2006-05-19 20:07     ` Miles Bader

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877jbqmrbc.fsf@jurta.org \
    --to=juri@jurta.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).