[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
From: |
Robert Pluim |
Subject: |
Re: 29.0.60; keymap-local-set and keymap-global-set became less strict |
Date: |
Wed, 01 Feb 2023 14:44:26 +0100 |
>>>>> 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
--
- Re: 29.0.60; keymap-local-set and keymap-global-set became less strict, Robert Pluim, 2023/02/01
- Re: 29.0.60; keymap-local-set and keymap-global-set became less strict, Eli Zaretskii, 2023/02/01
- Re: 29.0.60; keymap-local-set and keymap-global-set became less strict, Daniel Mendler, 2023/02/01
- Re: 29.0.60; keymap-local-set and keymap-global-set became less strict, Eli Zaretskii, 2023/02/01
- Re: 29.0.60; keymap-local-set and keymap-global-set became less strict, Daniel Mendler, 2023/02/01
- Re: 29.0.60; keymap-local-set and keymap-global-set became less strict, Eli Zaretskii, 2023/02/01
- Re: 29.0.60; keymap-local-set and keymap-global-set became less strict, Daniel Mendler, 2023/02/01
- Re: 29.0.60; keymap-local-set and keymap-global-set became less strict, Stefan Monnier, 2023/02/01
- Re: 29.0.60; keymap-local-set and keymap-global-set became less strict, Daniel Mendler, 2023/02/01
- Re: 29.0.60; keymap-local-set and keymap-global-set became less strict, Stefan Monnier, 2023/02/01
- Re: 29.0.60; keymap-local-set and keymap-global-set became less strict, Daniel Mendler, 2023/02/01
- Re: 29.0.60; keymap-local-set and keymap-global-set became less strict, Eli Zaretskii, 2023/02/02