Re: M-g in dired

[Juri Linkov]

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