RE: [External] : New key binding syntax

[Drew Adams <drew.adams@oracle.com>]

(Thanks for considering this.)

> I agree with your points 1, 2, 4, 5 and 6.
> 
>   > 7. I'm in favor of letting `kbd' and Help descriptions
>   > drop the use of angle brackets altogether.
> 
> I agree that that would be good -- provided no ambiguity results.
> Does anyone see a concrete problem with this?

That's my question too.  As I say, I haven't
run into any problem.  And I've asked for
counter-examples.

The place where we treat things specially is
for the ASCII control keys that have names
(aka abbreviations): NUL, RET, LFD, ESC, SPC,
and DEL.  And, IMO, TAB (see bug #12535).

Other that handling of those names specially
(which we already do in `edmacro-parse-keys',
and which is carried over into the no-angles
case by naked.el), I think there is nothing
special.  `foobar' is handled just as is
`<foobar>', and there can't be any problem.

[We could even look into the possibility of
"function" key names that include more chars
than what we accept now.  That might require
some finessing (dunno).  E.g., if we allowed
`<' and `>' then things get interesting (not
in a good way): `<<foo>>', `foo', `<foo>',
`foo>',...]

>   > 3. Personally, I don't feel a need to allow the
>   > argument to `kbd' to be used on its own (e.g., passed
>   > to `define-key" or its replacement), in place of using
>   > (kbd ARG) - let alone feel a need to prescribe that.
> 
> To allow the new syntax in arguments to old functions such as
> `define-key'  would be desirable if it doesn't cause problems.
> But I think it would lead to incompatibilities or conflicts,
> where an argument has one meaning as a key sequence (old style)
> and another as an argument to `kbd', so I think we can't do it.

I agree.  And I don't think anything is gained
by being able to write (define-key "C-f" ...)
instead of (define-key (kbd "C-f") ...).  And
likewise for any replacement/alternative for
`define-key'.  I think it makes a lot of sense
to continue to use an envelope such as (kbd...).

That was my point #3.  It counters suggestions
that we drop `kbd' (or another such name) as an
envelope, and we just use its (string) argument
directly in `define-key' (or whatever replaces
`define-key').

> I suggest defining new functions to replace
> `define-key' and friends, that will take a
> new-style key sequence as argument and will
> NOT accept an old-style key sequence.

What do you mean by new-style and old-style?
Are you talking, as I was above, about the
proposal to get rid of using `kbd' (or other
name), and just using strings: "C-f" instead
of (kbd "C-f")?  Or are you talking about
something else?

>   > \"S o m\" is _not_ a key sequence.  It's not a
>   > "sequence of the keys 'S', 'o' and 'm'".
> 
> I can't make head or tail of that.  Why the
> backslashes before those doublequotes?

Ask Lars.  He's the one who wrote that, in
the doc-string text you cited.  Presumably
those backslashes were just escaping the `"'
chars in the doc string.  But since you kept
them in the doc-string text that you quoted
and asked us to look at, I kept them also.

But my point there was not about that, at
all.  My point was that a key sequence is a
sequence of keys, whereas a notation "S o m"
is a key-sequence _description_.

That's all.  We should be clear about that
distinction, whether (1) talking among
ourselves about what syntax to use/allow or
(2) talking to users in doc strings.
(Please read again what I said about this.)

> With the default Emacs key bindings, S o m is not a valid
> key sequence, because S is not a prefix key.
> But it COULD be a valid key sequence if you defined S
> as a prefix key, then defined S o as a prefix key.

Yes, of course.  Presumably in the case cited
(in Lars's doc string), "S o m" would be a
(description of) a valid key sequence, with
both `S' and `o' being defined as prefix keys.