[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [External] : New key binding syntax
From: |
Drew Adams |
Subject: |
RE: [External] : New key binding syntax |
Date: |
Wed, 10 Nov 2021 17:24:34 +0000 |
(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.
- Re: [External] : New key binding syntax, (continued)
- Re: [External] : New key binding syntax, Alexandre Garreau, 2021/11/18
- Re: [External] : New key binding syntax, Stefan Kangas, 2021/11/18
- Re: [External] : New key binding syntax, Richard Stallman, 2021/11/18
- Re: [External] : New key binding syntax, Alexandre Garreau, 2021/11/19
- Re: [External] : New key binding syntax, Po Lu, 2021/11/19
- Re: [External] : New key binding syntax, Eli Zaretskii, 2021/11/19
- Re: [External] : New key binding syntax, Alexandre Garreau, 2021/11/19
- Re: [External] : New key binding syntax, Eli Zaretskii, 2021/11/19
- Re: [External] : New key binding syntax, Alexandre Garreau, 2021/11/19
- RE: [External] : New key binding syntax, Drew Adams, 2021/11/16
- RE: [External] : New key binding syntax,
Drew Adams <=