unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Mendler <mail@daniel-mendler.de>
Cc: rpluim@gmail.com, larsi@gnus.org, emacs-devel@gnu.org,
	monnier@iro.umontreal.ca
Subject: Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Wed, 01 Feb 2023 19:30:18 +0200	[thread overview]
Message-ID: <83mt5xz42d.fsf@gnu.org> (raw)
In-Reply-To: <309dee07-e404-4f84-a839-8b99815376f8@daniel-mendler.de> (message from Daniel Mendler on Wed, 1 Feb 2023 14:57:16 +0100)

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



  reply	other threads:[~2023-02-01 17:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5876987d-2479-f512-5767-218c8c16a909@daniel-mendler.de>
     [not found] ` <875ycngyji.fsf@gnus.org>
2023-01-31  9:05   ` 29.0.60; keymap-local-set and keymap-global-set became less strict Robert Pluim
2023-01-31 10:08     ` Stephen Berman
2023-01-31 14:27       ` [External] : " Drew Adams
2023-01-31 14:30     ` Stefan Monnier
2023-01-31 15:02       ` Robert Pluim
2023-01-31 15:06     ` Eli Zaretskii
2023-01-31 15:48       ` Robert Pluim
2023-01-31 16:37         ` Eli Zaretskii
2023-01-31 16:48           ` Robert Pluim
2023-01-31 18:43             ` Eli Zaretskii
2023-02-01 12:52               ` Robert Pluim
2023-02-01 13:06                 ` Eli Zaretskii
2023-02-01 13:13                   ` Daniel Mendler
2023-02-01 13:44                     ` Robert Pluim
2023-02-01 14:11                       ` Daniel Mendler
2023-02-01 13:50                     ` Eli Zaretskii
2023-02-01 13:57                       ` Daniel Mendler
2023-02-01 17:30                         ` Eli Zaretskii [this message]
2023-02-01 18:20                           ` Daniel Mendler
2023-02-01 18:54                             ` Stefan Monnier
2023-02-01 20:22                               ` Daniel Mendler
2023-02-01 22:42                                 ` Stefan Monnier
2023-02-01 22:56                                   ` Daniel Mendler
2023-02-02  6:58                                     ` Eli Zaretskii
2023-02-02  9:29                                       ` Daniel Mendler
2023-02-02  9:40                                       ` Robert Pluim
2023-02-02 10:17                                         ` Eli Zaretskii
2023-02-03  9:17                                           ` Robert Pluim
2023-02-03  9:56                                   ` Richard Stallman
2023-02-04  9:55                                     ` Daniel Mendler
2023-02-03  9:56                           ` Richard Stallman
2023-02-03 12:11                             ` Eli Zaretskii
2023-02-05  4:27                               ` Richard Stallman
2023-02-05  7:11                                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83mt5xz42d.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    --cc=mail@daniel-mendler.de \
    --cc=monnier@iro.umontreal.ca \
    --cc=rpluim@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).