* bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict
@ 2023-01-30 20:52 Daniel Mendler
2023-01-30 21:00 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Daniel Mendler @ 2023-01-30 20:52 UTC (permalink / raw)
To: 61184; +Cc: Lars Ingebrigtsen, Robert Pluim, Stefan Monnier
In patch f67a9a12b7b0cdd6030cb080a6d6838255789a08, the commands
keymap-local-set and keymap-global-set became less strict for
non-interactive use, which is not the intended the design. The goal is
that the API only accepts strings in a single format. The vector to
string conversion should happen within the interactive form.
There was an old commit by Stefan Monnier, where he relaxed the API, but
Lars made it clear back then that it is better to only accept a single
format for the keymap API, such that guidance for the user is better due
to clear error messages.
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict
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-31 3:42 ` Lars Ingebrigtsen
2023-01-31 12:10 ` Eli Zaretskii
2 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-01-30 21:00 UTC (permalink / raw)
To: Daniel Mendler; +Cc: larsi, 61184, rpluim
> In patch f67a9a12b7b0cdd6030cb080a6d6838255789a08, the commands
> keymap-local-set and keymap-global-set became less strict for
> non-interactive use, which is not the intended the design. The goal is
> that the API only accepts strings in a single format. The vector to
> string conversion should happen within the interactive form.
I don't see any use for the vector->string conversion to happen in the
interactive spec: I think the most important use cases for accepting
vectors is when these come directly from Lisp, in which case having to
convert them back to the KBD syntax (only to hope `key-parse` will
correctly undo the damage) is just a waste and a hurdle.
> There was an old commit by Stefan Monnier, where he relaxed the API, but
> Lars made it clear back then that it is better to only accept a single
> format for the keymap API, such that guidance for the user is better due
> to clear error messages.
Obviously, I disagree: the vector format is not going anywhere, so it
makes a lot sense to accept it, even though I fully agree that guidance
should never suggest the use of the vector format.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict
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
0 siblings, 1 reply; 16+ messages in thread
From: Daniel Mendler @ 2023-01-30 21:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: larsi, 61184, rpluim
On 1/30/23 22:00, Stefan Monnier wrote:
> I don't see any use for the vector->string conversion to happen in the
> interactive spec: I think the most important use cases for accepting
> vectors is when these come directly from Lisp, in which case having to
> convert them back to the KBD syntax (only to hope `key-parse` will
> correctly undo the damage) is just a waste and a hurdle.
> Obviously, I disagree: the vector format is not going anywhere, so it
> makes a lot sense to accept it, even though I fully agree that guidance
> should never suggest the use of the vector format.
Stefan, I know that you disagree, see the other thread. I am not the one
to debate this with. Please discuss this with Lars, who introduced the
API and intended it to be as strict as it was. Now the API gets relaxed
through the backdoor because of the broken interactive use. This is why
I am objecting.
All I want is that the keymap.el API overall is consistent - currently
it is not. The keymap-local/global-set made parts of the API accept
vectors, key-parse accepts invalid strings and the rest seems to only
accept strictly conforming key strings.
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.
Daniel
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict
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
0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-01-30 21:45 UTC (permalink / raw)
To: Daniel Mendler; +Cc: larsi, 61184, rpluim
> 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`.
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.
Stefan
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict
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
0 siblings, 0 replies; 16+ messages in thread
From: Daniel Mendler @ 2023-01-30 22:03 UTC (permalink / raw)
To: Stefan Monnier; +Cc: larsi, 61184, rpluim
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict
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-31 3:42 ` Lars Ingebrigtsen
[not found] ` <87zg9zvzuc.fsf@gmail.com>
2023-01-31 12:10 ` Eli Zaretskii
2 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2023-01-31 3:42 UTC (permalink / raw)
To: Daniel Mendler; +Cc: 61184, rpluim, monnier
Daniel Mendler <mail@daniel-mendler.de> writes:
> There was an old commit by Stefan Monnier, where he relaxed the API, but
> Lars made it clear back then that it is better to only accept a single
> format for the keymap API, such that guidance for the user is better due
> to clear error messages.
Yes, that was kinda the point of the whole keymap-* thing. If there's
one clear syntax, it makes many "but will this work, then?" problems
users have go away -- there's a lot of trial and error involved
currently.
In addition, having one single syntax allows people to grep for bindings
etc -- when exploring the source code, they can isearch for `C-c C-k'
(or whatever) exactly and reliably find the command they're looking for
that way (eventually).
So keymap-local-set and keymap-global-set should be fixed to be strict
again, otherwise there's not much point to the entire `keymap-*'
exercise.
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict
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-31 3:42 ` Lars Ingebrigtsen
@ 2023-01-31 12:10 ` Eli Zaretskii
2023-01-31 12:49 ` Daniel Mendler
2 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2023-01-31 12:10 UTC (permalink / raw)
To: Daniel Mendler; +Cc: larsi, 61184, rpluim, monnier
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Robert Pluim <rpluim@gmail.com>,
> Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 30 Jan 2023 21:52:54 +0100
> From: Daniel Mendler <mail@daniel-mendler.de>
>
> In patch f67a9a12b7b0cdd6030cb080a6d6838255789a08, the commands
> keymap-local-set and keymap-global-set became less strict for
> non-interactive use, which is not the intended the design.
Please tell more about that, because I don't yet see how that commit
made the non-interactive (and only non-interactive) invocations check
the argument less strictly.
Thanks.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict
2023-01-31 12:10 ` Eli Zaretskii
@ 2023-01-31 12:49 ` Daniel Mendler
2023-01-31 14:16 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Daniel Mendler @ 2023-01-31 12:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 61184, rpluim, monnier
On 1/31/23 13:10, Eli Zaretskii wrote:
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Robert Pluim <rpluim@gmail.com>,
>> Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Mon, 30 Jan 2023 21:52:54 +0100
>> From: Daniel Mendler <mail@daniel-mendler.de>
>>
>> In patch f67a9a12b7b0cdd6030cb080a6d6838255789a08, the commands
>> keymap-local-set and keymap-global-set became less strict for
>> non-interactive use, which is not the intended the design.
>
> Please tell more about that, because I don't yet see how that commit
> made the non-interactive (and only non-interactive) invocations check
> the argument less strictly.
The function became less strict since it also accepts vector arguments
now. The intended design by Lars was to only accept strings, and only
strings which are valid according to `key-valid-p'.
Daniel
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict
2023-01-31 12:49 ` Daniel Mendler
@ 2023-01-31 14:16 ` Eli Zaretskii
2023-01-31 14:53 ` Daniel Mendler
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2023-01-31 14:16 UTC (permalink / raw)
To: Daniel Mendler; +Cc: larsi, 61184, rpluim, monnier
> Date: Tue, 31 Jan 2023 13:49:11 +0100
> Cc: 61184@debbugs.gnu.org, larsi@gnus.org, rpluim@gmail.com,
> monnier@iro.umontreal.ca
> From: Daniel Mendler <mail@daniel-mendler.de>
>
> The function became less strict since it also accepts vector arguments
> now.
Because after the change it calls key-description? Or due to
something else?
If the call to key-description is the problem, we could make it only
in the interactive case, I think? Would that fix the problem?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict
2023-01-31 14:16 ` Eli Zaretskii
@ 2023-01-31 14:53 ` Daniel Mendler
2023-02-03 9:19 ` Robert Pluim
0 siblings, 1 reply; 16+ messages in thread
From: Daniel Mendler @ 2023-01-31 14:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 61184, rpluim, monnier
On 1/31/23 15:16, Eli Zaretskii wrote:
>> Date: Tue, 31 Jan 2023 13:49:11 +0100
>> Cc: 61184@debbugs.gnu.org, larsi@gnus.org, rpluim@gmail.com,
>> monnier@iro.umontreal.ca
>> From: Daniel Mendler <mail@daniel-mendler.de>
>>
>> The function became less strict since it also accepts vector arguments
>> now.
>
> Because after the change it calls key-description? Or due to
> something else?
Yes, because of the conversion by key-description.
> If the call to key-description is the problem, we could make it only
> in the interactive case, I think? Would that fix the problem?
Yes, that would work as I already suggested in my original mail.
Daniel
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict
2023-01-31 14:53 ` Daniel Mendler
@ 2023-02-03 9:19 ` Robert Pluim
0 siblings, 0 replies; 16+ messages in thread
From: Robert Pluim @ 2023-02-03 9:19 UTC (permalink / raw)
To: Daniel Mendler; +Cc: Eli Zaretskii, 61184, larsi, monnier
tags 61184 fixed
close 61184 29.1
quit
>>>>> On Tue, 31 Jan 2023 15:53:01 +0100, Daniel Mendler <mail@daniel-mendler.de> said:
Daniel> On 1/31/23 15:16, Eli Zaretskii wrote:
>>> Date: Tue, 31 Jan 2023 13:49:11 +0100
>>> Cc: 61184@debbugs.gnu.org, larsi@gnus.org, rpluim@gmail.com,
>>> monnier@iro.umontreal.ca
>>> From: Daniel Mendler <mail@daniel-mendler.de>
>>>
>>> The function became less strict since it also accepts vector arguments
>>> now.
>>
>> Because after the change it calls key-description? Or due to
>> something else?
Daniel> Yes, because of the conversion by key-description.
>> If the call to key-description is the problem, we could make it only
>> in the interactive case, I think? Would that fix the problem?
Daniel> Yes, that would work as I already suggested in my original mail.
Daniel> Daniel
The re-fix for 61149 fixes this
Robert
--
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2023-02-03 9:19 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2023-01-31 3:42 ` Lars Ingebrigtsen
[not found] ` <87zg9zvzuc.fsf@gmail.com>
[not found] ` <871qnbnhhy.fsf@rub.de>
2023-01-31 10:23 ` 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 12:10 ` 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
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).