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

[Robert Pluim]

>>>>> On Thu, 19 Jan 2023 11:39:34 +0100, Daniel Mendler 
>>>>> <mail@daniel-mendler.de> said:

    Daniel> 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?

    Daniel> Just try something like this:

    Daniel> (key-valid-p "bug")
    Daniel> (key-parse "bug")

Ah, the old "do we have to put spaces between keys" issue. Iʼm not
sure how best to deal with that, Iʼll have to read through keymap.el
some more. This:

(keymap-set k "a" "bug")

is already invalid, you have to write either

(keymap-set k "a" "b u g")

or

(keymap-set k "a" (kmacro "b u g"))

(Iʼm still tempted to change `kbd' to *always* return a vector, even
if all the characters are ASCII)

    >> 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 :-)

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

I know emacs-29 hasnʼt been released yet, but changing a function to
error by default when it didnʼt do previously seems risky. Iʼll make
that change locally and see what happens. (Update: it did not go well,
there are test-suite failures).

Robert
--