bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less s


From: Daniel Mendler
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

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 via email to

[Prev in Thread] Current Thread [Next in Thread]