GNU bug report logs - #61184
29.0.60; keymap-local-set and keymap-global-set became less strict

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61184 in the body.
You can then email your comments to 61184 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: bug-gnu-emacs <at> gnu.org
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Robert Pluim <rpluim <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Mon, 30 Jan 2023 21:52:54 +0100

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.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, bug-gnu-emacs <at> gnu.org,
 Robert Pluim <rpluim <at> gmail.com>
Subject: Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Mon, 30 Jan 2023 16:00:51 -0500

> 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

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, bug-gnu-emacs <at> gnu.org,
 Robert Pluim <rpluim <at> gmail.com>
Subject: Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Mon, 30 Jan 2023 22:06:01 +0100

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

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, bug-gnu-emacs <at> gnu.org,
 Robert Pluim <rpluim <at> gmail.com>
Subject: Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Mon, 30 Jan 2023 16:45:56 -0500

> 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

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, bug-gnu-emacs <at> gnu.org,
 Robert Pluim <rpluim <at> gmail.com>
Subject: Re: 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

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: bug-gnu-emacs <at> gnu.org, Robert Pluim <rpluim <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Tue, 31 Jan 2023 04:42:25 +0100

Daniel Mendler <mail <at> 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.

Message #23 received at 61184 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 61184 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Tue, 31 Jan 2023 11:23:36 +0100

(and redirecting back to bug#61184. EMORECOFFEE this morning)

>>>>> On Tue, 31 Jan 2023 11:08:41 +0100, Stephen Berman <stephen.berman <at> gmx.net> said:

    >> 
    >> OK. How about this then (why are the `cursor-in-echo-area' shenanigans
    >> necessary? I wonder if thatʼs a bug, since without them we either get
    >> the cursor not showing in the minibuffer for
    >> `read-key-sequence-vector', or we get an extra space displayed by
    >> `read-command')

    Stephen> TIL cursor-in-echo-area :-).  This looks to me like a
    Stephen> good solution

I looked at callint.c to figure out why `read-key-sequence' and
(interactive "K") were different (why *are* they different?)

    Stephen> (though aesthetically I would add a space after the colon in the
    Stephen> read-key-sequence-vector prompt, even though the user input doesn't
    Stephen> appear there).

If you do that you get two spaces between the colon and the cursor.

Robert
-- 

Message #26 received at 61184 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 61184 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Tue, 31 Jan 2023 11:31:29 +0100

On Tue, 31 Jan 2023 11:23:36 +0100 Robert Pluim <rpluim <at> gmail.com> wrote:

> (and redirecting back to bug#61184. EMORECOFFEE this morning)
>
>>>>>> On Tue, 31 Jan 2023 11:08:41 +0100, Stephen Berman
> <stephen.berman <at> gmx.net> said:
>
>     >> 
>     >> OK. How about this then (why are the `cursor-in-echo-area' shenanigans
>     >> necessary? I wonder if thatʼs a bug, since without them we either get
>     >> the cursor not showing in the minibuffer for
>     >> `read-key-sequence-vector', or we get an extra space displayed by
>     >> `read-command')
>
>     Stephen> TIL cursor-in-echo-area :-).  This looks to me like a
>     Stephen> good solution
>
> I looked at callint.c to figure out why `read-key-sequence' and
> (interactive "K") were different

Ah, ok.

>                                  (why *are* they different?)

Good question.

>     Stephen> (though aesthetically I would add a space after the colon in the
>     Stephen> read-key-sequence-vector prompt, even though the user input doesn't
>     Stephen> appear there).
>
> If you do that you get two spaces between the colon and the cursor.

Hm, I see just one space here with Emacs 29 and master (GNU/Linux)...

Steve Berman

Message #29 received at 61184 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 61184 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Tue, 31 Jan 2023 11:37:19 +0100

>>>>> On Tue, 31 Jan 2023 11:31:29 +0100, Stephen Berman <stephen.berman <at> gmx.net> said:

    Stephen> On Tue, 31 Jan 2023 11:23:36 +0100 Robert Pluim <rpluim <at> gmail.com> wrote:
    >> (and redirecting back to bug#61184. EMORECOFFEE this morning)
    >> 
    >>>>>>> On Tue, 31 Jan 2023 11:08:41 +0100, Stephen Berman
    >> <stephen.berman <at> gmx.net> said:
    >> 
    >> >> 
    >> >> OK. How about this then (why are the `cursor-in-echo-area' shenanigans
    >> >> necessary? I wonder if thatʼs a bug, since without them we either get
    >> >> the cursor not showing in the minibuffer for
    >> >> `read-key-sequence-vector', or we get an extra space displayed by
    >> >> `read-command')
    >> 
    Stephen> TIL cursor-in-echo-area :-).  This looks to me like a
    Stephen> good solution
    >> 
    >> I looked at callint.c to figure out why `read-key-sequence' and
    >> (interactive "K") were different

    Stephen> Ah, ok.

    >> (why *are* they different?)

    Stephen> Good question.

    Stephen> (though aesthetically I would add a space after the colon in the
    Stephen> read-key-sequence-vector prompt, even though the user input doesn't
    Stephen> appear there).
    >> 
    >> If you do that you get two spaces between the colon and the cursor.

    Stephen> Hm, I see just one space here with Emacs 29 and master (GNU/Linux)...

including in a tty frame? I see one space in gui, two in
tty. Redisplay expert to the white courtesy phone please.

Robert
-- 

Message #32 received at 61184 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 61184 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Tue, 31 Jan 2023 11:44:06 +0100

On Tue, 31 Jan 2023 11:37:19 +0100 Robert Pluim <rpluim <at> gmail.com> wrote:

>>>>>> On Tue, 31 Jan 2023 11:31:29 +0100, Stephen Berman
> <stephen.berman <at> gmx.net> said:
>
>     Stephen> On Tue, 31 Jan 2023 11:23:36 +0100 Robert Pluim
>     Stephen> <rpluim <at> gmail.com> wrote:
>     >> (and redirecting back to bug#61184. EMORECOFFEE this morning)
>     >> 
>     >>>>>>> On Tue, 31 Jan 2023 11:08:41 +0100, Stephen Berman
>     >> <stephen.berman <at> gmx.net> said:
>     >> 
>     >> >> 
>     >> >> OK. How about this then (why are the `cursor-in-echo-area' shenanigans
>     >> >> necessary? I wonder if thatʼs a bug, since without them we either get
>     >> >> the cursor not showing in the minibuffer for
>     >> >> `read-key-sequence-vector', or we get an extra space displayed by
>     >> >> `read-command')
>     >> 
>     Stephen> TIL cursor-in-echo-area :-).  This looks to me like a
>     Stephen> good solution
>     >> 
>     >> I looked at callint.c to figure out why `read-key-sequence' and
>     >> (interactive "K") were different
>
>     Stephen> Ah, ok.
>
>     >> (why *are* they different?)
>
>     Stephen> Good question.
>
>     Stephen> (though aesthetically I would add a space after the colon in the
>     Stephen> read-key-sequence-vector prompt, even though the user input doesn't
>     Stephen> appear there).
>     >> 
>     >> If you do that you get two spaces between the colon and the cursor.
>
>     Stephen> Hm, I see just one space here with Emacs 29 and master (GNU/Linux)...
>
> including in a tty frame? I see one space in gui, two in
> tty. Redisplay expert to the white courtesy phone please.

Ah, yes.  I'd only tested with -Q, not with -Q -nw.  I also see two in
the latter.  Yet more questions...

Steve Berman

Message #35 received at 61184 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: larsi <at> gnus.org, 61184 <at> debbugs.gnu.org, rpluim <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#61184: 29.0.60;
 keymap-local-set and keymap-global-set became less strict
Date: Tue, 31 Jan 2023 14:10:28 +0200

> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Robert Pluim <rpluim <at> gmail.com>,
>  Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Mon, 30 Jan 2023 21:52:54 +0100
> From: Daniel Mendler <mail <at> 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.

Message #38 received at 61184 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 61184 <at> debbugs.gnu.org, rpluim <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#61184: 29.0.60; keymap-local-set and keymap-global-set became
 less strict
Date: Tue, 31 Jan 2023 13:49:11 +0100

On 1/31/23 13:10, Eli Zaretskii wrote:
>> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Robert Pluim <rpluim <at> gmail.com>,
>>  Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Date: Mon, 30 Jan 2023 21:52:54 +0100
>> From: Daniel Mendler <mail <at> 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

Message #41 received at 61184 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: larsi <at> gnus.org, 61184 <at> debbugs.gnu.org, rpluim <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#61184: 29.0.60; keymap-local-set and keymap-global-set became
 less strict
Date: Tue, 31 Jan 2023 16:16:32 +0200

> Date: Tue, 31 Jan 2023 13:49:11 +0100
> Cc: 61184 <at> debbugs.gnu.org, larsi <at> gnus.org, rpluim <at> gmail.com,
>  monnier <at> iro.umontreal.ca
> From: Daniel Mendler <mail <at> 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?

Message #44 received at 61184 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 61184 <at> debbugs.gnu.org, rpluim <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#61184: 29.0.60; keymap-local-set and keymap-global-set became
 less strict
Date: Tue, 31 Jan 2023 15:53:01 +0100

On 1/31/23 15:16, Eli Zaretskii wrote:
>> Date: Tue, 31 Jan 2023 13:49:11 +0100
>> Cc: 61184 <at> debbugs.gnu.org, larsi <at> gnus.org, rpluim <at> gmail.com,
>>  monnier <at> iro.umontreal.ca
>> From: Daniel Mendler <mail <at> 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

Message #47 received at 61184 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: mail <at> daniel-mendler.de, larsi <at> gnus.org, stephen.berman <at> gmx.net,
 monnier <at> iro.umontreal.ca, 61184 <at> debbugs.gnu.org
Subject: Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
Date: Tue, 31 Jan 2023 18:06:11 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,  Daniel Mendler
>  <mail <at> daniel-mendler.de>,  61184 <at> debbugs.gnu.org,  Stefan Monnier
>  <monnier <at> iro.umontreal.ca>,  Eli Zaretskii <eliz <at> gnu.org>
> Date: Tue, 31 Jan 2023 11:37:19 +0100
> 
> >>>>> On Tue, 31 Jan 2023 11:31:29 +0100, Stephen Berman <stephen.berman <at> gmx.net> said:
> 
>     >> (why *are* they different?)
> 
>     Stephen> Good question.
> 
>     Stephen> (though aesthetically I would add a space after the colon in the
>     Stephen> read-key-sequence-vector prompt, even though the user input doesn't
>     Stephen> appear there).
>     >> 
>     >> If you do that you get two spaces between the colon and the cursor.
> 
>     Stephen> Hm, I see just one space here with Emacs 29 and master (GNU/Linux)...
> 
> including in a tty frame? I see one space in gui, two in
> tty. Redisplay expert to the white courtesy phone please.

You called?

That's a bug: two separate code paths that did equivalent jobs --
almost.  Walking glyphs is a tricksy business...

Should be fixed now.

Message #50 received at 61184 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 61184 <at> debbugs.gnu.org, larsi <at> gnus.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#61184: 29.0.60; keymap-local-set and keymap-global-set
 became less strict
Date: Fri, 03 Feb 2023 10:19:44 +0100

tags 61184 fixed
close 61184 29.1
quit

>>>>> On Tue, 31 Jan 2023 15:53:01 +0100, Daniel Mendler <mail <at> 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 <at> debbugs.gnu.org, larsi <at> gnus.org, rpluim <at> gmail.com,
    >>> monnier <at> iro.umontreal.ca
    >>> From: Daniel Mendler <mail <at> 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
-- 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.