[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: where-is only mentions first key in interval

From: Drew Adams
Subject: RE: where-is only mentions first key in interval
Date: Mon, 13 Feb 2012 09:06:14 -0800

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]