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

[Daniel Mendler]

On 2/1/23 14:50, Eli Zaretskii wrote:
> So?  A malevolent enough programmer could replace
> keymap-global/local-set with an implementation that performs the
> conversion unconditionally, so the danger of someone hanging
> themselves with the rope Emacs gives them always exists.  This
> function is supposed to help those who _want_ such problems to be
> caught, it isn't supposed to make Emacs a high-security prison,
> because that's simply impossible in Emacs.

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.

My suggestion is to go with one of these three solutions:

- Use `call-interactively-p'
- Use Stefan's proposal of a separate function `keymap--read' which is
called in the interactive form.
- Use Stefan's other proposal to allow vectors for all keymap functions
consistently. This way we don't have to jump through hoops here.

>> 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.
> 
> Excuse me, but that's the tail wagging the dog.  Please be reasonable,
> we want a change that is simple and safe enough to go into Emacs 29,
> because currently those functions are completely useless as
> interactive commands, and we want them to become the mainstay of
> binding keys interactively.

I think the patch proposed before was fairly reasonable, and could be
even improved with a separate `keymap--read' function as Stefan
proposed. It is less intrusive than the patch which has been proposed
now with the additional INTERACTIVE argument, which modifies the
interface. Adding an argument is a more intrusive change.

>> As better alternative we could also go with Stefan's proposal to allow
>> vectors as arguments in the first place.
> 
> Over Lars's disagreement?  I don't want to do that, with all due
> respect to Stefan, certainly not on emacs-29.

Okay, that's fine with me. I am fine with both allowing vectors and not
allowing vectors. But I am not fine with making a mess out of an API
which have been designed newly from the ground.

Daniel