bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t argument

[Daniel Mendler]

On 1/19/23 11:16, Robert Pluim wrote:
>     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?

Just try something like this:

(key-valid-p "bug")
(key-parse "bug")
>     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 :-)

I don't think so since of all these functions are new. These seem like
simple internal refactorings. Adding a NOERROR argument to key-parse
seems like the least intrusive approach.

Daniel