GNU bug report logs - #64927
30.0.50; kill-ring with no X

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: m43cap <at> yandex.com, Lars Ingebrigtsen <larsi <at> gnus.org>,
 64927 <at> debbugs.gnu.org
Subject: Re: bug#64927: 30.0.50; kill-ring with no X
Date: Thu, 03 Aug 2023 11:11:24 -0400

> This also affects Emacs 29, and is a regression from Emacs 28, which
> is related to the use of the new key-* functions.  Specifically, the
> error is signaled by the call to key-valid-p issued by
> possibly_translate_key_sequence, which is a subroutine of lookup-key.
> The argument KEY of possibly_translate_key_sequence in this case is a
> vector whose only element is a string with text properties:
>
>   [#("create a file" 0 13 (face font-lock-comment-face fontified t))]
>
> key-valid-p doesn't support such strings, it expects strings that
> describe key sequences.
>
> Significantly, possibly_translate_key_sequence calls key-parse after
> it calls key-valid-p, and key-parse copes with this string quite well.

No, `key-parse` doesn't handle this correctly either.

The ["create a file"] above is an "internal" key-sequence of length
1 that happens to use a string as the sole key.

`possibly_translate_key_sequence` instead is trying to handle the new
"external" key-sequence format [<KBDSTRING>] where <KBDSTRING> is using
the `kbd` syntax, i.e. the string is not itself a key but represents
a key-sequence.

IOW, this is a fundamental incompatibility introduced by the support for
this new [<KBDSTRING>] format in `define-key`: keys cannot be arbitrary
objects any more (among other things they can't be strings any more).


        Stefan

Previous Next

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