[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argumen
From: |
Robert Pluim |
Subject: |
bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument |
Date: |
Thu, 19 Jan 2023 11:16:24 +0100 |
>>>>> On Thu, 19 Jan 2023 11:08:07 +0100, Daniel Mendler
>>>>> <mail@daniel-mendler.de> said:
Daniel> On 1/19/23 10:55, Robert Pluim wrote:
>> And of course the following for consistency for `keymap-lookup' as
>> well. I now firmly believe that the new keymap functions should use
>> `key-parse' and not `kbd'.
Daniel> Robert, speaking of `key-parse', I wonder why this function accepts
Daniel> invalid key strings. Why don't we move the `key-valid-p' check to
Daniel> `key-parse'? This would alleviate the need for many additional
Daniel> `key-valid-p' checks across keymap.el. One could maybe even get rid
of
Daniel> the `keymap--check' helper.
Do you have an example of such an invalid string?
Daniel> The function `key-parse' is publicly exposed to the user and as
such it
Daniel> would be good if it were as strict as the rest of the keymap.el API.
Daniel> However `kbd' has been reimplemented based on `key-parse' which
prevents
Daniel> `key-parse' from being more strict. One could either introduce a
Daniel> `key--parse-lax` function which is used by `kbd' and `key-parse'
(plus a
Daniel> `key-valid-p' check) or add a NOERROR/NOVALIDATE argument to
Daniel> `key-parse', which is then used by `kbd'. What do you think?
>> Eli, is this too much for emacs-29?
Daniel> While it is late for 29, these APIs were newly and I believe it
would be
Daniel> better to improve them now, such that they don't have to change
again in
Daniel> the next release.
I think itʼs too late to make such changes for emacs-29. Iʼm not even
sure that the minimal changes I proposed will be accepted :-)
Robert
--
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Daniel Mendler, 2023/01/16
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Robert Pluim, 2023/01/17
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Daniel Mendler, 2023/01/17
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Robert Pluim, 2023/01/18
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Daniel Mendler, 2023/01/18
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Robert Pluim, 2023/01/19
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Daniel Mendler, 2023/01/19
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument,
Robert Pluim <=
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Daniel Mendler, 2023/01/19
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Robert Pluim, 2023/01/19
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Daniel Mendler, 2023/01/19
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Robert Pluim, 2023/01/19
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Daniel Mendler, 2023/01/19
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Eli Zaretskii, 2023/01/19
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Robert Pluim, 2023/01/19
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Eli Zaretskii, 2023/01/19
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Robert Pluim, 2023/01/19
- bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument, Robert Pluim, 2023/01/20