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

[Eli Zaretskii]

> Date: Wed, 1 Feb 2023 14:57:16 +0100
> Cc: rpluim@gmail.com, larsi@gnus.org, emacs-devel@gnu.org,
>  monnier@iro.umontreal.ca
> From: Daniel Mendler <mail@daniel-mendler.de>
> 
> 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.

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.

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.

> >> 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.

Not from my POV.  The patch was complex, was using a different
interfaces (which surely will bring some unintended surprises, like
any read-WHATEVER API used to read input), and relying on obscure
options like cursor-in-echo-area that evidently is not used much in
these cases (or else the bug with cursor positioning on TTY frames
would have been reported long ago).  From where I stand, it's
antithesis of safe changes close to pretest.

> 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.