all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Daniel Mendler <mail@daniel-mendler.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: larsi@gnus.org, 61184@debbugs.gnu.org, rpluim@gmail.com
Subject: bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Mon, 30 Jan 2023 23:03:03 +0100	[thread overview]
Message-ID: <9fd41d2c-4d75-271b-d3a8-8ca8d5e6229a@daniel-mendler.de> (raw)
In-Reply-To: <jwvlelj7l6u.fsf-monnier+emacs@gnu.org>

On 1/30/23 22:45, Stefan Monnier wrote:
>> I think what Lars had in mind with a strict string-only API for
>> keymap.el, since this creates a consistent picture for keymap
>> definitions. I agree that internally the vectors are not going away and
>> that is okay, but this does not prohibit creating the more strict
>> superficial string only API.
> 
> It's still a PITA when you have a vector and you need to pass it to
> a function which happens to be usually receiving its data from end-users
> and hence passes its inputs through `key-parse`.

I tend to agree. Also I recently had to write a few times (keymap-set
map "<remap> <too>" #'long) where I would have preferred to write
(keymap-set map [remap not] #'long). The same with `defvar-keymap' which
also needs this long remap syntax.

> Accepting vectors in `key-parse` doesn't prevent the construction of
> a consistent picture where end users only need to know about
> KBD-style strings.

Yes, but I am no fan of "hiding the truth" in the documentation. It
would not be bad to accept both the strict string syntax and vectors,
and also document that. It would still be consistent, maybe even more so
when considering the whole Emacs where many internal keymap and event
functions operate on vectors.

I hope it is not too late to fix the API for Emacs 29 such that it
becomes consistent. When the API is officially released it is harder to
change it.

All functions should only accept the strict string syntax as defined by
key-valid-p, including the key-parse function. As Stefan argues, the
functions could also accept vectors, but then please - all of them. I
would not mind that and may prefer it in some cases like the remapping
or when you already have another vector anyway.

On the other ahnd I also see the merits of the more restricted string
only API, which would be simpler to explain and one would not have to
hide the truth in the doc string. For internal uses with vectors there
are still define-key and the other APIs.

Daniel





  reply	other threads:[~2023-01-30 22:03 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-30 20:52 bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict Daniel Mendler
2023-01-30 21:00 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-30 21:06   ` Daniel Mendler
2023-01-30 21:45     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-30 22:03       ` Daniel Mendler [this message]
2023-01-31  3:42 ` Lars Ingebrigtsen
2023-01-31  9:05   ` Robert Pluim
2023-01-31 10:08     ` Stephen Berman
2023-01-31 10:23       ` bug#61184: " Robert Pluim
2023-01-31 10:31         ` Stephen Berman
2023-01-31 10:37           ` Robert Pluim
2023-01-31 10:44             ` Stephen Berman
2023-01-31 16:06             ` Eli Zaretskii
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
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
2023-01-31 12:10 ` bug#61184: " Eli Zaretskii
2023-01-31 12:49   ` Daniel Mendler
2023-01-31 14:16     ` Eli Zaretskii
2023-01-31 14:53       ` Daniel Mendler
2023-02-03  9:19         ` Robert Pluim

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

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

  git send-email \
    --in-reply-to=9fd41d2c-4d75-271b-d3a8-8ca8d5e6229a@daniel-mendler.de \
    --to=mail@daniel-mendler.de \
    --cc=61184@debbugs.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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.