where-is only mentions first key in interval

where-is only mentions first key in interval

[Per Starbäck]

I did  C-h w dired-find-file  in dired and was surprised that the
answer

  dired-find-file is on RET, e, <menu-bar> <immediate> <find-file>

didn't include 'f' which also is bound to dired-find-file.

It's because 'e' and 'f' come directly after each other.
'where-is-internal' returns

  ([13] [(101 . 102)] [menu-bar immediate find-file])

which includes the interval e..f (101..102), and then 'where-is' maps
'key-description' on that, and

  (key-description [(101 . 102)]) returns just "e".

Is this a bug or just a misfeature?

With Emacs 22.3 the answer is instead the better

 dired-find-file is on f, e, <menu-bar> <immediate> <find-file>;
  its alias dired-advertised-find-file is on RET

but from Emacs 23 'f' is no longer mentioned. (That includes current
23.4 and current pretest 24.0.93.

Re: where-is only mentions first key in interval

[Stefan Monnier]

>   (key-description [(101 . 102)]) returns just "e".

I've installed the patch below, so it will display as
"dired-find-file is on RET, e..f, <menu-bar>"
It would be better to handle such "trivial" intervals as separate keys,
but that's a larger change (because "C-x e..f" needs to be turned into
"C-x e, C-x f").


        Stefan


=== modified file 'src/keymap.c'
--- src/keymap.c	2012-01-19 07:21:25 +0000
+++ src/keymap.c	2012-02-13 15:52:25 +0000
@@ -2270,9 +2270,15 @@
   if (CONSP (key) && lucid_event_type_list_p (key))
     key = Fevent_convert_list (key);
 
+  if (CONSP (key) && INTEGERP (XCAR (key)) && INTEGERP (XCDR (key)))
+    /* An interval from a map-char-table.  */
+    return concat3 (Fsingle_key_description (XCAR (key), no_angles),
+		    build_string (".."),
+		    Fsingle_key_description (XCDR (key), no_angles));
+
   key = EVENT_HEAD (key);
 
-  if (INTEGERP (key))		/* Normal character */
+  if (INTEGERP (key))		/* Normal character.  */
     {
       char tem[KEY_DESCRIPTION_SIZE], *p;
 
@@ -2280,7 +2286,7 @@
       *p = 0;
       return make_specified_string (tem, -1, p - tem, 1);
     }
-  else if (SYMBOLP (key))	/* Function key or event-symbol */
+  else if (SYMBOLP (key))	/* Function key or event-symbol.  */
     {
       if (NILP (no_angles))
 	{

RE: where-is only mentions first key in interval

[Drew Adams]

> I've installed the patch below, so it will display as
> "dired-find-file is on RET, e..f, <menu-bar>"
> It would be better to handle such "trivial" intervals as 
> separate keys, but that's a larger change (because
> "C-x e..f" needs to be turned into "C-x e, C-x f").

If that latter fix is not going to be made instead of what you describe, then I
think the original bug is better than what you describe.  This should be fixed
right - it is a regression wrt Emacs 22 and prior.

This is user help, and help about keys, no less - the most important place to be
clear wrt key descriptions.

Per Emacs key notation, `e..f' means only one thing: the sequence of four
keystrokes `e', `.', `.', and `f'.

Re: where-is only mentions first key in interval

[Per Starbäck]

> Per Emacs key notation, `e..f' means only one thing: the sequence of four
> keystrokes `e', `.', `.', and `f'.

But that is written 'e . . f' of course! Emacs already uses ".." for
intervals at least for describe-bindings,
but with spaces, like:

SPC .. ~	self-insert-command

RE: where-is only mentions first key in interval

[Drew Adams]

> > Per Emacs key notation, `e..f' means only one thing: the 
> > sequence of four keystrokes `e', `.', `.', and `f'.
> 
> But that is written 'e . . f' of course!

Well, yes (`e . . f', not 'e . . f').

But in the `where-is' output there are no `' wrappers: spaces are generally used
to separate keys.  That too is a problem (to be fixed, IMO): Sometimes a space
separates key sequences, sometimes it does not: "C-x C-f", for example.

But given the use of spaces here to separate keys, a user might very easily
think (wrongly) that e..f represents a single key sequence.

And if you tried to introduce spaces to separate those keys, like "e .. f", that
falsely communicates three key bindings: `e', `..', and `f'.  And it does not in
any way communicate the fact that `..' means "and everything between".

And even the notion of "everything between" is not so clear in this context.
This is not obviously a list of bindings ordered by character code.  A user
might be able to guess "e..f" here, but "SPC..~" would perhaps not be so clear.
And there is nothing in the doc of `where-is' or even `where-is-internal' that
describes the order used in the key-sequence output (another problem to be
fixed, IMO).

Obviously, just "e f" would be OK here.  It was what was used prior to Emacs 23.
Returning to that would fix the regression, even if it wouldn't make `C-h w'
output crystal clear.

> Emacs already uses ".." for intervals at least for
> describe-bindings, but with spaces, like:
> 
> SPC .. ~	self-insert-command

Completely different context.  (And there too, things could be improved, IMO, by
providing a better column header or a legend that says what `..' represents.
And state what order is used for the table rows.)

If we cannot immediately improve the `where-is' output then we should at least
restore the behavior prior to this regression, i.e., prior to Emacs 23.