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

[Daniel Mendler <mail@daniel-mendler.de>]

On 2/1/23 18:30, Eli Zaretskii wrote:
>> Of course everything is possible. But that's not my point here. The
>> keymap.el API is a newly designed API, so please let's design it in a
>> clean way, where we don't have meaningless arguments.
> 
> The advertised API wouldn't change.  We don't expect anyone to use the
> additional argument in non-interactive invocation.  We can use
> advertised-calling-convention declaration to hide that argument from
> documented interfaces.

That's good. If the argument is not advertised then the implementation
detail is at least hidden superficially.

> I'm also okay with using called-interactively-p, but I thought for
> once we should do what we preach.  (And whoever wants to circumvent
> called-interactively-p can always use call-interactively anyway.)  But
> if people dislike the method that we ourselves document as the
> preferred one, I can live with the second best.
I think call-interactively-p would be better for this use case, but
that's my opinion versus yours.

>> I am not fine with making a mess out of an API which have been
>> designed newly from the ground.
> 
> We are not messing anything, see above.  These are all accepted,
> documented, and recommended techniques.  I get it that you don't like
> them, but the documentation clearly indicates that your opinions on
> this are not shared by the project.

Actually, I agree that using an interactive argument is an acceptable
approach in some cases. I use this technique myself in some of my
projects published on GNU ELPA, so what you write is factually wrong.
But if there is a rule or recommended technique, there can also be an
exception.

I still believe it is better to not leak implementation details as an
optional argument in this case, even if it is hidden via the advertised
calling convention. Robert mentioned that an additional interactive type
K could be introduced. That might be a good long term solution, but
requires more intrusive changes which are out of question for emacs-29.

Daniel