Re: 29.0.60; keymap-local-set and keymap-global-set became less strict

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Wed, 1 Feb 2023 14:13:25 +0100, Daniel Mendler <mail@daniel-mendler.de> said:

    >> Yes, exactly.  Thanks.
    >> 
    >> Unless anyone else objects, please install this in a day or two.

    Daniel> I object. With this change the non-interactive implementation is
    Daniel> polluted with an unnecessary INTERACTIVE argument, which would then
    Daniel> allow the non-interactive caller to still pass vector arguments. You
    Daniel> could as well call the argument ALLOW-VECTOR. If the non-interactive
    Daniel> function gets extended at some point with additional arguments how
    Daniel> should we proceed then? I also argue that the primary use case of these
    Daniel> functions is non-interactive and that should be prioritized.

I use `local-set-key' interactively all the time, so Iʼm not convinced
thatʼs generally true.

    Daniel> Why can you not just move the whole conversion business into the
    Daniel> `interactive' form? This means we cannot use a string as interactive
    Daniel> form but we have to implement our own `keymap--read` function which is
    Daniel> then used like this: `(interactive (list (keymap--read ...) ...))`. It
    Daniel> is not as concise as the string form but would avoid any problems.

Thatʼs basically my previous patch with the repetitive code moved into
a separate function as Stefan suggested. Or we could avoid the extra
arg by using `called-interactively-p'

    Daniel> As better alternative we could also go with Stefan's proposal to allow
    Daniel> vectors as arguments in the first place. This would resolve this issue
    Daniel> cleanly without any extra code.

And this goes against Larsʼ intentions for the new keymap code, so I
donʼt think thatʼs a good idea.

Maybe Iʼll just implement my 'Κ' idea ;-)

Robert
--