emacs-devel
[Top][All Lists]
Advanced

[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: Daniel Mendler
Subject: Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Wed, 1 Feb 2023 14:13:25 +0100


On 2/1/23 14:06, Eli Zaretskii wrote:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: larsi@gnus.org,  mail@daniel-mendler.de,  emacs-devel@gnu.org,
>>   monnier@iro.umontreal.ca
>> Date: Wed, 01 Feb 2023 13:52:19 +0100
>>
>>>>>>> On Tue, 31 Jan 2023 20:43:09 +0200, Eli Zaretskii <eliz@gnu.org> said:
>>
>>     Eli> What's wrong with the first method described in the node 
>> "Distinguish
>>     Eli> Interactive" in the ELisp reference?
>>
>> You mean like this? Itʼs definitely a smaller change.
> 
> Yes, exactly.  Thanks.
> 
> Unless anyone else objects, please install this in a day or two.

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

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

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

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]