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

[Daniel Mendler]

On 2/1/23 14:44, Robert Pluim wrote:
>>>>>> 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.

I base my argument on the fact that many users modify keybindings in
their user configuration. However this applies more to
`keymap-globl-set' or `global-set-key'. But there is not much point in
arguing about such statistics since we want to have both non-interactive
and interactive use supported.

My point is that in a newly designed keymap API there should not be a
place for such superfluous arguments which are only a leak of the
underlying implementation to support the interactive use case.

>     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'

Yes, your patch plus Stefan's improvement proposal seems like a
reasonable solution to me.

>     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.

Yes, it does. But I am neutral with respect to that decision. I would be
okay if all keymap functions accepted vectors as I would be if they
don't. But given that we have to jump through hoops to achieve our goal,
maybe relaxing the strictness would indeed be better as Stefan proposed.

Daniel