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

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

On 2/2/23 07:58, Eli Zaretskii wrote:
>>> Emacs is not in the business of imposing The Right Way, instead we
>>> prefer to encourage it while still allowing people to shoot themselves
>>> in the foot in all kinds of fun ways.
>>
>> Tell that to Eli, who seems to be in the business of preaching The Right
>> Way and also following it.
> 
> But preaching is very different from imposing.  And I think "do as I
> say, not as I do" is not a great stance for us (although we sometimes
> do it).

You preach and impose it on the new API. But it is okay.

>> But that's beside the point - keymap.el is a newly introduced library
>> with a newly designed API. I would expect that such a library can be
>> implemented according to the best practices without any kludges -
>> without `call-interactively-p' and without advertised calling
>> conventions. That this does not seem to be possible, leaves me
>> unsatisfied. Well, it would actually be possible, we just have to do it
>> differently - either allowing vectors as arguments or by using a
>> different interactive form calling `keymap--read-key`. But these better
>> solutions were rejected for other reasons.
> 
> We could go for a different design if we had more time.  These
> functions were introduced just 2.5 months ago, and the problems with
> them were only brought to our attention very recently.  We don't have
> enough time to switch to using other APIs in the interactive form, as
> we had bitter experience with doing that in similar cases (subtle bugs
> and behavior changes that took many moons to uncover and even longer
> to fix).  It's too bad no one tried these new commands earlier and
> reported the problems back then, but that's water under the bridge.
> So we don't have the luxury of going for the ideal design.  We must
> choose one of the safe solutions that will not delay the pretest nor
> endanger its quick success and the following release.  I prefer the
> additional argument method, and it sounds like so does Stefan.

I agree that we should be careful for emacs-29. I think you convinced me
that the additional (non-advertised) argument isn't worse than
`call-interactively-p'. I would still prefer a solution without either
of those kludges (or maybe even just allowing vector arguments to avoid
the complications), but I've repeated that often enough. Maybe when the
API is overhauled the next time.

Thanks for the consideration and thanks for addressing this issue in the
first place.

Daniel