unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Daniel Mendler <mail@daniel-mendler.de>
To: Robert Pluim <rpluim@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	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, 1 Feb 2023 15:11:02 +0100	[thread overview]
Message-ID: <01093ff6-213e-6486-609f-d80b779f8ac3@daniel-mendler.de> (raw)
In-Reply-To: <877cx1o5z9.fsf@gmail.com>

On 2/1/23 14:44, Robert Pluim wrote:
>>>>>> On Wed, 1 Feb 2023 14:13:25 +0100, Daniel Mendler <mail@daniel-mendler.de> said:
> 
>     >> Yes, exactly.  Thanks.
>     >> 
>     >> Unless anyone else objects, please install this in a day or two.
> 
>     Daniel> I object. With this change the non-interactive implementation is
>     Daniel> polluted with an unnecessary INTERACTIVE argument, which would then
>     Daniel> allow the non-interactive caller to still pass vector arguments. You
>     Daniel> could as well call the argument ALLOW-VECTOR. If the non-interactive
>     Daniel> function gets extended at some point with additional arguments how
>     Daniel> should we proceed then? I also argue that the primary use case of these
>     Daniel> functions is non-interactive and that should be prioritized.
> 
> I use `local-set-key' interactively all the time, so Iʼm not convinced
> thatʼs generally true.

I base my argument on the fact that many users modify keybindings in
their user configuration. However this applies more to
`keymap-globl-set' or `global-set-key'. But there is not much point in
arguing about such statistics since we want to have both non-interactive
and interactive use supported.

My point is that in a newly designed keymap API there should not be a
place for such superfluous arguments which are only a leak of the
underlying implementation to support the interactive use case.

>     Daniel> Why can you not just move the whole conversion business into the
>     Daniel> `interactive' form? This means we cannot use a string as interactive
>     Daniel> form but we have to implement our own `keymap--read` function which is
>     Daniel> then used like this: `(interactive (list (keymap--read ...) ...))`. It
>     Daniel> is not as concise as the string form but would avoid any problems.
> 
> Thatʼs basically my previous patch with the repetitive code moved into
> a separate function as Stefan suggested. Or we could avoid the extra
> arg by using `called-interactively-p'

Yes, your patch plus Stefan's improvement proposal seems like a
reasonable solution to me.

>     Daniel> As better alternative we could also go with Stefan's proposal to allow
>     Daniel> vectors as arguments in the first place. This would resolve this issue
>     Daniel> cleanly without any extra code.
> 
> And this goes against Larsʼ intentions for the new keymap code, so I
> donʼt think thatʼs a good idea.

Yes, it does. But I am neutral with respect to that decision. I would be
okay if all keymap functions accepted vectors as I would be if they
don't. But given that we have to jump through hoops to achieve our goal,
maybe relaxing the strictness would indeed be better as Stefan proposed.

Daniel



  reply	other threads:[~2023-02-01 14:11 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 [this message]
2023-02-01 13:50                     ` Eli Zaretskii
2023-02-01 13:57                       ` Daniel Mendler
2023-02-01 17:30                         ` Eli Zaretskii
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=01093ff6-213e-6486-609f-d80b779f8ac3@daniel-mendler.de \
    --to=mail@daniel-mendler.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    --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).