Re: master 570a11052b: keymap.el: Ease up support for non-`kbd` formats.

Re: master 570a11052b: keymap.el: Ease up support for non-`kbd` formats.

[Lars Ingebrigtsen]

(Re-sent to the right emacs-devel address...)

Stefan Monnier via Mailing list for Emacs changes <emacs-diffs@gnu.org>
writes:

>     While we want to standardize on the `kbd` syntax for user-facing code,
>     the internal vector representation of key sequences is not going away,
>     so let's not impose silly `key-description + key-parse` roundtrips.

I don't think this is a good idea.  Before this change, `keymap-set'
(and friends) provided real value in giving the users feedback on the
consistent format we've chosen to document support.  With this, you
reintroduce the confusion we have with the myriad different (and
incomplete) syntaxes, and the next question will inevitably be why
`keymap-set' doesn't support the rest.

We've discussed this to death already.

So I'm going to revert this change, unless there's a compelling case not
to.

Re: master 570a11052b: keymap.el: Ease up support for non-`kbd` formats.

[Stefan Monnier]

> (Re-sent to the right emacs-devel address...)

[ Same here ;-)  ]

> Stefan Monnier via Mailing list for Emacs changes <emacs-diffs@gnu.org>
> writes:
>
>>     While we want to standardize on the `kbd` syntax for user-facing code,
>>     the internal vector representation of key sequences is not going away,
>>     so let's not impose silly `key-description + key-parse` roundtrips.
>
> I don't think this is a good idea.  Before this change, `keymap-set'
> (and friends) provided real value in giving the users feedback on the
> consistent format we've chosen to document support.  With this, you
> reintroduce the confusion we have with the myriad different (and
> incomplete) syntaxes, and the next question will inevitably be why
> `keymap-set' doesn't support the rest.

I thought I explained in the commit message: the low-level vector
representation is not going away any time soon (there's not even a plan
for how this could happen, or anyone who mentioned a desire to make it
happen).

So it makes no sense to force people through (key-parse (key-description
<vector>)) when they have a low-level vector keysequence to start with.


        Stefan

Re: master 570a11052b: keymap.el: Ease up support for non-`kbd` formats.

[Lars Ingebrigtsen]

(Gah, wrong address again...  I really should fix that ecomplete thing
you suggested the other week, because otherwise "emacs-devel@gnus.org"
is going to be my emacs-devel completion forever.)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So it makes no sense to force people through (key-parse (key-description
> <vector>)) when they have a low-level vector keysequence to start with.

The sense it makes is that `key-parse' takes one and only one syntax --
which is easy to conceptualise.  If they have a key representation in a
different format (for historical or other reasons), they should
translate that to the advertised format like that.

We've been over this before, several times.  I understand that you
disagree, but you're not saying anything new.

Re: master 570a11052b: keymap.el: Ease up support for non-`kbd` formats.

[Stefan Monnier]

>> So it makes no sense to force people through (key-parse (key-description
>> <vector>)) when they have a low-level vector keysequence to start with.
>
> The sense it makes is that `key-parse' takes one and only one syntax --

And my patch does not change that.


        Stefan