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 #38 received at 60867 <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>, 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 12:05:36 +0100
>>>>> On Thu, 19 Jan 2023 11:39:34 +0100, Daniel Mendler <mail <at> daniel-mendler.de> said:

    Daniel> 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?

    Daniel> Just try something like this:

    Daniel> (key-valid-p "bug")
    Daniel> (key-parse "bug")

Ah, the old "do we have to put spaces between keys" issue. Iʼm not
sure how best to deal with that, Iʼll have to read through keymap.el
some more. This:

(keymap-set k "a" "bug")

is already invalid, you have to write either

(keymap-set k "a" "b u g")

or

(keymap-set k "a" (kmacro "b u g"))

(Iʼm still tempted to change `kbd' to *always* return a vector, even
if all the characters are ASCII)

    >> 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 :-)

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

I know emacs-29 hasnʼt been released yet, but changing a function to
error by default when it didnʼt do previously seems risky. Iʼll make
that change locally and see what happens. (Update: it did not go well,
there are test-suite failures).

Robert
-- 




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.