GNU bug report logs - #52523
29.0.50; defcustom :type 'key-sequence not following key-valid-p format

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 52523 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: bug#52523: 29.0.50; defcustom :type 'key-sequence not following key-valid-p format
Date: Mon, 27 Dec 2021 13:05:11 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> I started looking into this but noticed that the docstring for
> `key-valid-p' says:
>
>     Say whether KEYS is a valid ‘kbd’ sequence.
>     A ‘kbd’ sequence is a string consisting of one and more key
>     strokes.  The key strokes are separated by a space character.
>
> I guess that docstring should be updated if we don't want to settle for
> the terminology "`kbd' sequence".

Yes, I forgot to update the doc string when I redid this.

> However, if we do that the problem is that we then risk having two
> definitions of "key sequence": both the old and the new style.
>
> See also (info "(elisp) Key Sequences"), that uses the old style.

Yes, that's confusing.  I meant to have the `key-valid-p' say what it
accepts as a valid key binding, and then the other functions refer to it.

> Relatedly, the `define-keymap' docstring currently says:
>
>     Create a new keymap and define KEY/DEFINITION pairs as key sequences.
>
> Should that say "key bindings" instead of "key sequences"?  Otherwise,
> it doesn't seem clear what it does.

Yes, it should.

> `keymap-set' says:
>
>     Set key sequence KEY to DEFINITION in KEYMAP.
>
> So here is again the "new" style used as the definition of a key
> sequence, which seems to contradict the Elisp manual.

Yes.  Please go ahead and fix up the doc strings.  😀

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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