GNU bug report logs - #60867
29.0.60; keymap-set-after does not accept the AFTER=t argument

Previous Next

Package: emacs;

Reported by: Daniel Mendler <mail <at> daniel-mendler.de>

Date: Mon, 16 Jan 2023 18:21:01 UTC

Severity: normal

Tags: fixed

Found in version 29.0.60

Fixed in version 29.1

Done: Robert Pluim <rpluim <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 60867 <at> debbugs.gnu.org
Subject: Re: bug#60867: 29.0.60; keymap-set-after does not accept the AFTER=t
 argument
Date: Thu, 19 Jan 2023 11:39:34 +0100
On 1/19/23 11:16, Robert Pluim wrote:
>     Daniel> Robert, speaking of `key-parse', I wonder why this function accepts
>     Daniel> invalid key strings. Why don't we move the `key-valid-p' check to
>     Daniel> `key-parse'? This would alleviate the need for many additional
>     Daniel> `key-valid-p' checks across keymap.el. One could maybe even get rid of
>     Daniel> the `keymap--check' helper.
> 
> Do you have an example of such an invalid string?

Just try something like this:

(key-valid-p "bug")
(key-parse "bug")
>     Daniel> The function `key-parse' is publicly exposed to the user and as such it
>     Daniel> would be good if it were as strict as the rest of the keymap.el API.
>     Daniel> However `kbd' has been reimplemented based on `key-parse' which prevents
>     Daniel> `key-parse' from being more strict. One could either introduce a
>     Daniel> `key--parse-lax` function which is used by `kbd' and `key-parse' (plus a
>     Daniel> `key-valid-p' check) or add a NOERROR/NOVALIDATE argument to
>     Daniel> `key-parse', which is then used by `kbd'. What do you think?
> 
>     >> Eli, is this too much for emacs-29?
> 
>     Daniel> While it is late for 29, these APIs were newly and I believe it would be
>     Daniel> better to improve them now, such that they don't have to change again in
>     Daniel> the next release.
> 
> I think itʼs too late to make such changes for emacs-29. Iʼm not even
> sure that the minimal changes I proposed will be accepted :-)

I don't think so since of all these functions are new. These seem like
simple internal refactorings. Adding a NOERROR argument to key-parse
seems like the least intrusive approach.

Daniel




This bug report was last modified 2 years and 117 days ago.

Previous Next


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