GNU bug report logs -
#79767
31.0.50; keymap-set-after warning or code wrong?
Previous Next
To reply to this bug, email your comments to 79767 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 09:20:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Pedro A. Aranda" <paaguti <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 05 Nov 2025 09:20:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
1.- put the following code in the *scratch* buffer an evaluate
(defun org-setup-menu ()
"Add refresh local variables to the org menu"
(interactive)
(keymap-set-after org-mode-map
;; [menu-bar org Restart/Reload]
"<menu-bar> <org> <Restart/Reload>"
'("Refresh local variables" . file-open)))
You will get a warning about wrong kbd syntax.
2. Put the following line in the *scratch* buffer and evaluate
(kbd "<menu-bar> <org> <Restart/Reload>")
It will be evaluated correctly...
Something is wrong with the error message while byte-compiling the function.
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0) of 2025-11-04 built on c3fb9206f1ba
Repository revision: 11860fe936cfbb9dc13ab728e5c9719b7e7721a3
Repository branch: master
System Description: Ubuntu 22.04.5 LTS
Configured using:
'configure --prefix=/usr --program-suffix=31 --with-compress-install
--with-modules=yes --with-threads --with-included-regex --with-zlib
--with-dbus --without-x --with-x-toolkit=gtk3 --with-cairo --with-pgtk
--with-native-compilation=aot 'CFLAGS=-g -O2
-ffile-prefix-map=/home/paag/emacs=. -flto=auto -ffat-lto-objects
-flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat
-Werror=format-security' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects
-flto=auto -Wl,-z,relro''
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBOTF
LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PGTK PNG
RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM GTK3 ZLIB
Important settings:
value of $LC_MONETARY: es_ES.UTF-8
value of $LC_NUMERIC: es_ES.UTF-8
value of $LC_TIME: es_ES.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-nonselected-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug lisp-mnt message mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode mailabbrev
gmm-utils mailheader sendmail mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils warnings icons compile
text-property-search comint ansi-osc ansi-color ring comp-run bytecomp
byte-compile comp-common rx time-date subr-x cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win
term/common-win touch-screen pgtk-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
multi-tty move-toolbar make-network-process tty-child-frames
native-compile emacs)
Memory information:
((conses 16 66666 11961) (symbols 48 6843 0) (strings 32 18248 2243)
(string-bytes 1 764362) (vectors 16 11159)
(vector-slots 8 155320 5068) (floats 8 31 107) (intervals 56 380 16)
(buffers 984 13))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 11:23:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 79767 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 5 Nov 2025 10:19:09 +0100, "Pedro A. Aranda" <paaguti <at> gmail.com> said:
Pedro> 1.- put the following code in the *scratch* buffer an evaluate
Pedro> (defun org-setup-menu ()
Pedro> "Add refresh local variables to the org menu"
Pedro> (interactive)
Pedro> (keymap-set-after org-mode-map
Pedro> ;; [menu-bar org Restart/Reload]
Pedro> "<menu-bar> <org> <Restart/Reload>"
Pedro> '("Refresh local variables" . file-open)))
Pedro> You will get a warning about wrong kbd syntax.
The function to use to check validity for keymap-* functions is
`key-valid-p', which complains about the above. If you get rid of the
'/' it wonʼt complain. It could be argued that we should allow it,
itʼs a small change.
Pedro> 2. Put the following line in the *scratch* buffer and evaluate
Pedro> (kbd "<menu-bar> <org> <Restart/Reload>")
Pedro> It will be evaluated correctly...
Pedro> Something is wrong with the error message while byte-compiling the function.
You havenʼt shown us what it is, so it is hard to reason about 🙂
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 13:02:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 79767 <at> debbugs.gnu.org (full text, mbox):
On 5/11/25 12:22, Robert Pluim wrote:
>>>>>> On Wed, 5 Nov 2025 10:19:09 +0100, "Pedro A. Aranda" <paaguti <at> gmail.com> said:
>
> Pedro> 1.- put the following code in the *scratch* buffer an evaluate
> Pedro> (defun org-setup-menu ()
> Pedro> "Add refresh local variables to the org menu"
> Pedro> (interactive)
> Pedro> (keymap-set-after org-mode-map
> Pedro> ;; [menu-bar org Restart/Reload]
> Pedro> "<menu-bar> <org> <Restart/Reload>"
> Pedro> '("Refresh local variables" . file-open)))
>
> Pedro> You will get a warning about wrong kbd syntax.
>
> The function to use to check validity for keymap-* functions is
> `key-valid-p', which complains about the above. If you get rid of the
> '/' it wonʼt complain. It could be argued that we should allow it,
> itʼs a small change.
org-mode's menu has an submenu that is "Restart/Reload". Maybe it
wouldn't be such a bad idea ;-)
>
> Pedro> 2. Put the following line in the *scratch* buffer and evaluate
>
> Pedro> (kbd "<menu-bar> <org> <Restart/Reload>")
>
> Pedro> It will be evaluated correctly...
>
> Pedro> Something is wrong with the error message while byte-compiling the function.
>
> You havenʼt shown us what it is, so it is hard to reason about 🙂
What it says is:
Warning: Invalid ‘kbd’ syntax: "<menu-bar> <org> <Restart/Reload>"
>
> Robert
/PA
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 14:07:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 79767 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 5 Nov 2025 14:01:02 +0100, "Pedro A. Aranda" <paaguti <at> gmail.com> said:
Pedro> On 5/11/25 12:22, Robert Pluim wrote:
>>>>>>> On Wed, 5 Nov 2025 10:19:09 +0100, "Pedro A. Aranda" <paaguti <at> gmail.com> said:
Pedro> 1.- put the following code in the *scratch* buffer an
>> evaluate
Pedro> (defun org-setup-menu ()
Pedro> "Add refresh local variables to the org menu"
Pedro> (interactive)
Pedro> (keymap-set-after org-mode-map
Pedro> ;; [menu-bar org Restart/Reload]
Pedro> "<menu-bar> <org> <Restart/Reload>"
Pedro> '("Refresh local variables" . file-open)))
Pedro> You will get a warning about wrong kbd syntax.
>> The function to use to check validity for keymap-* functions is
>> `key-valid-p', which complains about the above. If you get rid of the
>> '/' it wonʼt complain. It could be argued that we should allow it,
>> itʼs a small change.
Pedro> org-mode's menu has an submenu that is "Restart/Reload". Maybe it
Pedro> wouldn't be such a bad idea ;-)
The patch is small enough:
diff --git a/lisp/keymap.el b/lisp/keymap.el
index b418d157619..35c1809c1fb 100644
--- a/lisp/keymap.el
+++ b/lisp/keymap.el
@@ -383,7 +383,7 @@ key-valid-p
;; Don't accept Meta'd characters as keys.
(or (multibyte-string-p key)
(not (<= 127 (aref key 0) 255))))
- (and (string-match-p "\\`<[-_A-Za-z0-9]+>\\'" key)
+ (and (string-match-p "\\`<[-_A-Za-z0-9/]+>\\'" key)
;; Don't allow <M-C-down>.
(= (progn
(string-match
I canʼt think of any downsides at the moment, but Iʼll do some
searching through the Emacs sources.
Pedro> 2. Put the following line in the *scratch* buffer and
>> evaluate
Pedro> (kbd "<menu-bar> <org> <Restart/Reload>")
Pedro> It will be evaluated correctly...
Pedro> Something is wrong with the error message while
>> byte-compiling the function.
>> You havenʼt shown us what it is, so it is hard to reason about 🙂
Pedro> What it says is:
Pedro> Warning: Invalid ‘kbd’ syntax: "<menu-bar> <org> <Restart/Reload>"
Yes, thatʼs wrong, the underlying check actually uses
`key-valid-p'. The interactive check uses the following message:
(error "%S is not a valid key definition; see `key-valid-p'" key)))
so Iʼll adjust the compile-time check to match.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 15:08:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 79767 <at> debbugs.gnu.org (full text, mbox):
> Cc: 79767 <at> debbugs.gnu.org
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Wed, 05 Nov 2025 15:06:49 +0100
>
> >>>>> On Wed, 5 Nov 2025 14:01:02 +0100, "Pedro A. Aranda" <paaguti <at> gmail.com> said:
>
> Pedro> On 5/11/25 12:22, Robert Pluim wrote:
> >>>>>>> On Wed, 5 Nov 2025 10:19:09 +0100, "Pedro A. Aranda" <paaguti <at> gmail.com> said:
> Pedro> 1.- put the following code in the *scratch* buffer an
> >> evaluate
> Pedro> (defun org-setup-menu ()
> Pedro> "Add refresh local variables to the org menu"
> Pedro> (interactive)
> Pedro> (keymap-set-after org-mode-map
> Pedro> ;; [menu-bar org Restart/Reload]
> Pedro> "<menu-bar> <org> <Restart/Reload>"
> Pedro> '("Refresh local variables" . file-open)))
> Pedro> You will get a warning about wrong kbd syntax.
> >> The function to use to check validity for keymap-* functions is
> >> `key-valid-p', which complains about the above. If you get rid of the
> >> '/' it wonʼt complain. It could be argued that we should allow it,
> >> itʼs a small change.
>
> Pedro> org-mode's menu has an submenu that is "Restart/Reload". Maybe it
> Pedro> wouldn't be such a bad idea ;-)
>
> The patch is small enough:
>
> diff --git a/lisp/keymap.el b/lisp/keymap.el
> index b418d157619..35c1809c1fb 100644
> --- a/lisp/keymap.el
> +++ b/lisp/keymap.el
> @@ -383,7 +383,7 @@ key-valid-p
> ;; Don't accept Meta'd characters as keys.
> (or (multibyte-string-p key)
> (not (<= 127 (aref key 0) 255))))
> - (and (string-match-p "\\`<[-_A-Za-z0-9]+>\\'" key)
> + (and (string-match-p "\\`<[-_A-Za-z0-9/]+>\\'" key)
> ;; Don't allow <M-C-down>.
> (= (progn
> (string-match
>
> I canʼt think of any downsides at the moment, but Iʼll do some
> searching through the Emacs sources.
Do we really want to allow '/' in key symbols? And if we don't, how
can we discern between "keys" that are menu items and real keys or
pseudo-key symbols?
And why allow only '/' but not other punctuation characters?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 15:41:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 79767 <at> debbugs.gnu.org (full text, mbox):
Hi,
I can report back to org-mode and make Ihor change all the items in
org-mode that have a '/'...
But is org-mode the only place where this happens?
/PA
On 5/11/25 16:07, Eli Zaretskii wrote:
>> Cc: 79767 <at> debbugs.gnu.org
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Date: Wed, 05 Nov 2025 15:06:49 +0100
>>
>>>>>>> On Wed, 5 Nov 2025 14:01:02 +0100, "Pedro A. Aranda" <paaguti <at> gmail.com> said:
>>
>> Pedro> On 5/11/25 12:22, Robert Pluim wrote:
>> >>>>>>> On Wed, 5 Nov 2025 10:19:09 +0100, "Pedro A. Aranda" <paaguti <at> gmail.com> said:
>> Pedro> 1.- put the following code in the *scratch* buffer an
>> >> evaluate
>> Pedro> (defun org-setup-menu ()
>> Pedro> "Add refresh local variables to the org menu"
>> Pedro> (interactive)
>> Pedro> (keymap-set-after org-mode-map
>> Pedro> ;; [menu-bar org Restart/Reload]
>> Pedro> "<menu-bar> <org> <Restart/Reload>"
>> Pedro> '("Refresh local variables" . file-open)))
>> Pedro> You will get a warning about wrong kbd syntax.
>> >> The function to use to check validity for keymap-* functions is
>> >> `key-valid-p', which complains about the above. If you get rid of the
>> >> '/' it wonʼt complain. It could be argued that we should allow it,
>> >> itʼs a small change.
>>
>> Pedro> org-mode's menu has an submenu that is "Restart/Reload". Maybe it
>> Pedro> wouldn't be such a bad idea ;-)
>>
>> The patch is small enough:
>>
>> diff --git a/lisp/keymap.el b/lisp/keymap.el
>> index b418d157619..35c1809c1fb 100644
>> --- a/lisp/keymap.el
>> +++ b/lisp/keymap.el
>> @@ -383,7 +383,7 @@ key-valid-p
>> ;; Don't accept Meta'd characters as keys.
>> (or (multibyte-string-p key)
>> (not (<= 127 (aref key 0) 255))))
>> - (and (string-match-p "\\`<[-_A-Za-z0-9]+>\\'" key)
>> + (and (string-match-p "\\`<[-_A-Za-z0-9/]+>\\'" key)
>> ;; Don't allow <M-C-down>.
>> (= (progn
>> (string-match
>>
>> I canʼt think of any downsides at the moment, but Iʼll do some
>> searching through the Emacs sources.
>
> Do we really want to allow '/' in key symbols? And if we don't, how
> can we discern between "keys" that are menu items and real keys or
> pseudo-key symbols?
>
> And why allow only '/' but not other punctuation characters?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 16:01:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 79767 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 5 Nov 2025 16:40:47 +0100, "Pedro A. Aranda" <paaguti <at> gmail.com> said:
>> Do we really want to allow '/' in key symbols? And if we don't, how
>> can we discern between "keys" that are menu items and real keys or
>> pseudo-key symbols?
>> And why allow only '/' but not other punctuation characters?
Iʼm not sure I understand the issue. I donʼt think we have any
function key, menu item, or other pseudo-key symbols that contain '/',
nor do I think there are any real keys that are represented using a
symbol with '/' in it. Things like "C-/" are represented by "C-/", not
"<C-/>" (which both `kbd' and `key-parse' accept, but `key-valid-p'
rejects, both with and without allowing '/' in key symbols).
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 16:37:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 79767 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier
> <monnier <at> iro.umontreal.ca>, 79767 <at> debbugs.gnu.org
> Date: Wed, 05 Nov 2025 17:00:26 +0100
>
> >>>>> On Wed, 5 Nov 2025 16:40:47 +0100, "Pedro A. Aranda" <paaguti <at> gmail.com> said:
> >> Do we really want to allow '/' in key symbols? And if we don't, how
> >> can we discern between "keys" that are menu items and real keys or
> >> pseudo-key symbols?
> >> And why allow only '/' but not other punctuation characters?
>
> Iʼm not sure I understand the issue. I donʼt think we have any
> function key, menu item, or other pseudo-key symbols that contain '/',
> nor do I think there are any real keys that are represented using a
> symbol with '/' in it. Things like "C-/" are represented by "C-/", not
> "<C-/>" (which both `kbd' and `key-parse' accept, but `key-valid-p'
> rejects, both with and without allowing '/' in key symbols).
We are in violent agreement. I'm asking why allow them, since we
didn't have them till now, and didn't allow punctuation characters
except '-' and '_' in those names.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 16:38:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 79767 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 5 Nov 2025 16:40:47 +0100
> Cc: 79767 <at> debbugs.gnu.org
> From: "Pedro A. Aranda" <paaguti <at> gmail.com>
>
> I can report back to org-mode and make Ihor change all the items in
> org-mode that have a '/'...
We could, if we decide we don't want to allow that. But let's first
wait until the discussion arrives at some conclusions.
> But is org-mode the only place where this happens?
No.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 17:02:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 79767 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 05 Nov 2025 18:36:05 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier
>> <monnier <at> iro.umontreal.ca>, 79767 <at> debbugs.gnu.org
>> Date: Wed, 05 Nov 2025 17:00:26 +0100
>>
>> >>>>> On Wed, 5 Nov 2025 16:40:47 +0100, "Pedro A. Aranda" <paaguti <at> gmail.com> said:
>> >> Do we really want to allow '/' in key symbols? And if we don't, how
>> >> can we discern between "keys" that are menu items and real keys or
>> >> pseudo-key symbols?
>> >> And why allow only '/' but not other punctuation characters?
>>
>> Iʼm not sure I understand the issue. I donʼt think we have any
>> function key, menu item, or other pseudo-key symbols that contain '/',
>> nor do I think there are any real keys that are represented using a
>> symbol with '/' in it. Things like "C-/" are represented by "C-/", not
>> "<C-/>" (which both `kbd' and `key-parse' accept, but `key-valid-p'
>> rejects, both with and without allowing '/' in key symbols).
Eli> We are in violent agreement. I'm asking why allow them, since we
Eli> didn't have them till now, and didn't allow punctuation characters
Eli> except '-' and '_' in those names.
I misread your text, my apologies.
Thinking about it some more, those key symbols are not displayed to
the end user in any way (except via "C-h k" for a menu entry), so
keeping the restrictions as they are would be OK, but it would be a
slight incompatibility between `define-key-after' and
`keymap-set-after' (and would create work for org-mode developers).
Sounds like a decision for a maintainer, which Iʼm not 😀
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 18:19:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 79767 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 05 Nov 2025 18:37:47 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> Date: Wed, 5 Nov 2025 16:40:47 +0100
>> Cc: 79767 <at> debbugs.gnu.org
>> From: "Pedro A. Aranda" <paaguti <at> gmail.com>
>>
>> I can report back to org-mode and make Ihor change all the items in
>> org-mode that have a '/'...
Eli> We could, if we decide we don't want to allow that. But let's first
Eli> wait until the discussion arrives at some conclusions.
>> But is org-mode the only place where this happens?
Eli> No.
Where else? I couldnʼt find any in the Emacs sources, but maybe Iʼm
looking in the wrong place.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 19:33:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 79767 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: "Pedro A. Aranda" <paaguti <at> gmail.com>, monnier <at> iro.umontreal.ca,
> 79767 <at> debbugs.gnu.org
> Date: Wed, 05 Nov 2025 19:17:51 +0100
>
> >>>>> On Wed, 05 Nov 2025 18:37:47 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>
> >> But is org-mode the only place where this happens?
>
> Eli> No.
>
> Where else? I couldnʼt find any in the Emacs sources, but maybe Iʼm
> looking in the wrong place.
One example that always stares me right in the face when I work on
Emacs:
(easy-menu-define c-ts-mode-menu (list c-ts-mode-map c++-ts-mode-map)
"Menu for `c-ts-mode' and `c++-ts-mode'."
'("C/C++" <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Wed, 05 Nov 2025 20:54:03 GMT)
Full text and
rfc822 format available.
Message #41 received at 79767 <at> debbugs.gnu.org (full text, mbox):
> Pedro> 1.- put the following code in the *scratch* buffer an evaluate
> Pedro> (defun org-setup-menu ()
> Pedro> "Add refresh local variables to the org menu"
> Pedro> (interactive)
> Pedro> (keymap-set-after org-mode-map
> Pedro> ;; [menu-bar org Restart/Reload]
> Pedro> "<menu-bar> <org> <Restart/Reload>"
> Pedro> '("Refresh local variables" . file-open)))
>
> Pedro> You will get a warning about wrong kbd syntax.
>
> The function to use to check validity for keymap-* functions is
> `key-valid-p', which complains about the above. If you get rid of the
> '/' it wonʼt complain. It could be argued that we should allow it,
> itʼs a small change.
BTW, this points to a larger problem: the "key" names used for menu
entries can in general be completely arbitrary. E.g. easy-menu
generates them from the menu's text via `intern`.
So, `key-valid-p` (and `key-parse`) should allow "anything" as key name,
including a key name like `a> C-x <foo`.
IOW, I think we need to add support for some kind of escaping of
special characters.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Thu, 06 Nov 2025 06:17:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 79767 <at> debbugs.gnu.org (full text, mbox):
> Cc: "Pedro A. Aranda" <paaguti <at> gmail.com>, 79767 <at> debbugs.gnu.org
> Date: Wed, 05 Nov 2025 15:52:49 -0500
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> > Pedro> 1.- put the following code in the *scratch* buffer an evaluate
> > Pedro> (defun org-setup-menu ()
> > Pedro> "Add refresh local variables to the org menu"
> > Pedro> (interactive)
> > Pedro> (keymap-set-after org-mode-map
> > Pedro> ;; [menu-bar org Restart/Reload]
> > Pedro> "<menu-bar> <org> <Restart/Reload>"
> > Pedro> '("Refresh local variables" . file-open)))
> >
> > Pedro> You will get a warning about wrong kbd syntax.
> >
> > The function to use to check validity for keymap-* functions is
> > `key-valid-p', which complains about the above. If you get rid of the
> > '/' it wonʼt complain. It could be argued that we should allow it,
> > itʼs a small change.
>
> BTW, this points to a larger problem: the "key" names used for menu
> entries can in general be completely arbitrary. E.g. easy-menu
> generates them from the menu's text via `intern`.
> So, `key-valid-p` (and `key-parse`) should allow "anything" as key name,
> including a key name like `a> C-x <foo`.
> IOW, I think we need to add support for some kind of escaping of
> special characters.
Any idea why Lars specifically coded key-valid-p to disallow most
characters? That's definitely not an accident.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Thu, 06 Nov 2025 09:04:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 79767 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 05 Nov 2025 21:32:27 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: "Pedro A. Aranda" <paaguti <at> gmail.com>, monnier <at> iro.umontreal.ca,
>> 79767 <at> debbugs.gnu.org
>> Date: Wed, 05 Nov 2025 19:17:51 +0100
>>
>> >>>>> On Wed, 05 Nov 2025 18:37:47 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>>
>> >> But is org-mode the only place where this happens?
>>
Eli> No.
>>
>> Where else? I couldnʼt find any in the Emacs sources, but maybe Iʼm
>> looking in the wrong place.
Eli> One example that always stares me right in the face when I work on
Eli> Emacs:
Eli> (easy-menu-define c-ts-mode-menu (list c-ts-mode-map c++-ts-mode-map)
Eli> "Menu for `c-ts-mode' and `c++-ts-mode'."
Eli> '("C/C++" <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
So I was looking in the wrong place. Since that currently works, it
obviously doesnʼt go via `key-valid-p'. Iʼm assuming you donʼt want to
change that.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Thu, 06 Nov 2025 10:03:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 79767 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: 79767 <at> debbugs.gnu.org, paaguti <at> gmail.com, monnier <at> iro.umontreal.ca
> Date: Thu, 06 Nov 2025 10:03:07 +0100
>
> >>>>> On Wed, 05 Nov 2025 21:32:27 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>
> >> From: Robert Pluim <rpluim <at> gmail.com>
> >> Cc: "Pedro A. Aranda" <paaguti <at> gmail.com>, monnier <at> iro.umontreal.ca,
> >> 79767 <at> debbugs.gnu.org
> >> Date: Wed, 05 Nov 2025 19:17:51 +0100
> >>
> >> >>>>> On Wed, 05 Nov 2025 18:37:47 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
> >>
> >> >> But is org-mode the only place where this happens?
> >>
> Eli> No.
> >>
> >> Where else? I couldnʼt find any in the Emacs sources, but maybe Iʼm
> >> looking in the wrong place.
>
> Eli> One example that always stares me right in the face when I work on
> Eli> Emacs:
>
> Eli> (easy-menu-define c-ts-mode-menu (list c-ts-mode-map c++-ts-mode-map)
> Eli> "Menu for `c-ts-mode' and `c++-ts-mode'."
> Eli> '("C/C++" <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> So I was looking in the wrong place. Since that currently works, it
> obviously doesnʼt go via `key-valid-p'. Iʼm assuming you donʼt want to
> change that.
I'm not yet sure what is the conclusion of this discussion; see what
Stefan wrote.
But yes, easy-menu-define uses define-key, as you can easily see.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Thu, 06 Nov 2025 12:56:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 79767 <at> debbugs.gnu.org (full text, mbox):
> Any idea why Lars specifically coded key-valid-p to disallow most
> characters? That's definitely not an accident.
IIRC, the purpose of `key-valid-p` was to avoid mis-interpretations
(the predecessor to `key-parse`, i.e. `kbd`, tends to happily return
something even if it may not be what the author expected), so it was
made purposefully strict.
Relaxing it by allowing more characters should be done with care.
Adding one more character, used for escaping, would seem safe enough
to me.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Thu, 06 Nov 2025 14:05:02 GMT)
Full text and
rfc822 format available.
Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 06 Nov 2025 07:55:12 -0500, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> said:
>> Any idea why Lars specifically coded key-valid-p to disallow most
>> characters? That's definitely not an accident.
Stefan> IIRC, the purpose of `key-valid-p` was to avoid mis-interpretations
Stefan> (the predecessor to `key-parse`, i.e. `kbd`, tends to happily return
Stefan> something even if it may not be what the author expected), so it was
Stefan> made purposefully strict.
Stefan> Relaxing it by allowing more characters should be done with care.
Stefan> Adding one more character, used for escaping, would seem safe enough
Stefan> to me.
Allowing the use of a character to escape any subsequent character is
the same as allowing all characters:
foo\/bar
foo\🔔bar
etc
I think Iʼd prefer just allowing '/', since thatʼs commonly used in
menus. Or maybe allow it *only* via `easy-menu-define', but that then
precludes things like `keymap-set-after'.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Thu, 06 Nov 2025 14:05:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Thu, 06 Nov 2025 16:48:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 79767 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim [2025-11-06 15:04:10] wrote:
>>>>>> On Thu, 06 Nov 2025 07:55:12 -0500, Stefan Monnier via "Bug reports
> for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> said:
>
> >> Any idea why Lars specifically coded key-valid-p to disallow most
> >> characters? That's definitely not an accident.
>
> Stefan> IIRC, the purpose of `key-valid-p` was to avoid mis-interpretations
> Stefan> (the predecessor to `key-parse`, i.e. `kbd`, tends to happily return
> Stefan> something even if it may not be what the author expected), so it was
> Stefan> made purposefully strict.
>
> Stefan> Relaxing it by allowing more characters should be done with care.
> Stefan> Adding one more character, used for escaping, would seem safe enough
> Stefan> to me.
>
> Allowing the use of a character to escape any subsequent character is
> the same as allowing all characters:
>
> foo\/bar
> foo\🔔bar
>
> etc
As mentioned above, the purpose of `key-valid-p` was not to make it
impossible to use funny key names, but to catch errors where the users
get the syntax of keys wrong. E.g. catch misuses like "return".
So there's a big difference between allowing "<return C-x >"
and allowing "<return\\ C-x\\ >" because there's a much
lower likelihood that users will write the second by accident.
BTW, I'm using the usual \ as an escape character, like you did above,
but I don't know if that's the escape mechanism we should use:
we're talking about strings that are usually written in ELisp files, so
all \ would almost always need to be doubled.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Thu, 06 Nov 2025 17:57:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 79767 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 06 Nov 2025 11:47:34 -0500, Stefan Monnier <monnier <at> iro.umontreal.ca> said:
Stefan> As mentioned above, the purpose of `key-valid-p` was not to make it
Stefan> impossible to use funny key names, but to catch errors where the users
Stefan> get the syntax of keys wrong. E.g. catch misuses like "return".
Stefan> So there's a big difference between allowing "<return C-x >"
Stefan> and allowing "<return\\ C-x\\ >" because there's a much
Stefan> lower likelihood that users will write the second by accident.
Iʼm afraid Iʼm failing to understand what youʼre proposing. You said
earlier:
Stefan> Relaxing it by allowing more characters should be done with care.
Stefan> Adding one more character, used for escaping, would seem safe enough
Stefan> to me.
Implementing the second is not 'with care', it makes it open bar
(including having SPC in the symbol name).
Anyway, Iʼm voting for the status quo, and not changing
`easy-menu-define'. Maybe I could be persuaded that '/' should be
allowed, but no further.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Thu, 06 Nov 2025 20:25:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 79767 <at> debbugs.gnu.org (full text, mbox):
> Iʼm afraid Iʼm failing to understand what youʼre proposing. You said
> earlier:
>
> Stefan> Relaxing it by allowing more characters should be done with care.
>
> Stefan> Adding one more character, used for escaping, would seem safe enough
> Stefan> to me.
>
> Implementing the second is not 'with care', it makes it open bar
> (including having SPC in the symbol name).
I think you're confusing "what is allowed in an event name" with "what
is allowed in the `key-valid-p` syntax". Changing what is allowed in an
event name would be an incompatible change and the bug report was about
the `key-valid-p`, so I'm only talking about the `key-valid-p` syntax.
I'm not suggesting "open bar" at all: I'm suggesting to narrowly extend
the syntax so that all allowed event names have a corresponding syntax
in `key-valid-p` by adding an escaping mechanism.
"C-x <foo bar>" would *still* be an invalid syntax, so we'd
still catch most errors, which is the whole purpose of `key-valid-p`.
> Anyway, Iʼm voting for the status quo, and not changing
> `easy-menu-define'. Maybe I could be persuaded that '/' should be
> allowed, but no further.
I think it's a serious problem for `key-valid-p` to use a syntax that's
more restrictive than the events we use elsewhere.
The whole purpose of the new `keymap-*` functions and macros is to try
to hide the low-level representation of sequences of events (vector of
integers or symbols) and promote the more human-friendly `key-valid-p`
syntax instead. If that new syntax doesn't cover all cases, that's an
obstacle to its adoption.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Fri, 07 Nov 2025 06:39:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 79767 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, 6 Nov 2025 at 21:24, Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:
>
> I think it's a serious problem for `key-valid-p` to use a syntax that's
> more restrictive than the events we use elsewhere.
>
That's why I filed the bug. Apparently, I can write
(keymap-set-after org-mode-map
"<menu-bar> <org> <Customize>"
'("Refresh local variables" . refresh-local-variables)))
just because there is no '/' in the "<menu-bar>...", but byte-compile will
flag it if there is a '/'. Another thing is whether I can use this
"<menu-bar>..." because it is an entry or not.
It would be more useful to know that I can't use keymap-set-after with
"<menu-bar> <org> <Restart/Reload>"
because that is a nested menu header, not because of the "/" in it.
As a matter of fact, it should be perfectly possible to use
"<menu-bar> <org> <Restart/Reload> <Restart Org in Current Buffer>"
because that is a menu item, and currently it isn't.
> The whole purpose of the new `keymap-*` functions and macros is to try
> to hide the low-level representation of sequences of events (vector of
> integers or symbols) and promote the more human-friendly `key-valid-p`
> syntax instead. If that new syntax doesn't cover all cases, that's an
> obstacle to its adoption.
>
+1
>
> Stefan
>
My .2 cents,
/PA
PS: This new function will eventually make menu customisation easier to
understand (at least for me)
--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
"Sagen's Paradeiser" (ORF: Als Radiohören gefährlich war) => write BE!
Year 1 of the New Koprocracy
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Fri, 07 Nov 2025 07:57:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 79767 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
> 79767 <at> debbugs.gnu.org, paaguti <at> gmail.com
> Date: Thu, 06 Nov 2025 15:24:35 -0500
>
> > Anyway, Iʼm voting for the status quo, and not changing
> > `easy-menu-define'. Maybe I could be persuaded that '/' should be
> > allowed, but no further.
>
> I think it's a serious problem for `key-valid-p` to use a syntax that's
> more restrictive than the events we use elsewhere.
>
> The whole purpose of the new `keymap-*` functions and macros is to try
> to hide the low-level representation of sequences of events (vector of
> integers or symbols) and promote the more human-friendly `key-valid-p`
> syntax instead. If that new syntax doesn't cover all cases, that's an
> obstacle to its adoption.
I agree, but define-key allows the KEY argument to be any ASCII string
representing a valid sequence of keys or events. How do we
"translate" that to 'kbd' syntax? One way is to make key-valid-p be
permissive and rely on define-key to signal an error if the key is
invalid. Are there better ways that don't make key-valid-p more
restrictive than define-key?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Fri, 07 Nov 2025 12:37:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 79767 <at> debbugs.gnu.org (full text, mbox):
>> > Anyway, Iʼm voting for the status quo, and not changing
>> > `easy-menu-define'. Maybe I could be persuaded that '/' should be
>> > allowed, but no further.
>>
>> I think it's a serious problem for `key-valid-p` to use a syntax that's
>> more restrictive than the events we use elsewhere.
>>
>> The whole purpose of the new `keymap-*` functions and macros is to try
>> to hide the low-level representation of sequences of events (vector of
>> integers or symbols) and promote the more human-friendly `key-valid-p`
>> syntax instead. If that new syntax doesn't cover all cases, that's an
>> obstacle to its adoption.
>
> I agree, but define-key allows the KEY argument to be any ASCII string
> representing a valid sequence of keys or events. How do we
> "translate" that to 'kbd' syntax? One way is to make key-valid-p be
> permissive and rely on define-key to signal an error if the key is
> invalid.
That's not a full solution: (key-parse "<up> <up>") is already defined
to return [up up], so we need some new syntax to allow it to return
[up>\ <up] for event names like `up> <up`.
IOW, we need some escaping mechanism.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79767; Package
emacs.
(Tue, 11 Nov 2025 17:40:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 79767 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
any progress on this?
The obvious work-around is to place you items after a menu item that passes
valid-key-p, but
1) that's "sort of"
2) that eliminates all submenu items in a submenu that has a "damned
character", so not useful for adding items to the "<C/C++>" menu, for
example.
My .2cents, /PA
On Fri, 7 Nov 2025 at 13:36, Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:
> >> > Anyway, Iʼm voting for the status quo, and not changing
> >> > `easy-menu-define'. Maybe I could be persuaded that '/' should be
> >> > allowed, but no further.
> >>
> >> I think it's a serious problem for `key-valid-p` to use a syntax that's
> >> more restrictive than the events we use elsewhere.
> >>
> >> The whole purpose of the new `keymap-*` functions and macros is to try
> >> to hide the low-level representation of sequences of events (vector of
> >> integers or symbols) and promote the more human-friendly `key-valid-p`
> >> syntax instead. If that new syntax doesn't cover all cases, that's an
> >> obstacle to its adoption.
> >
> > I agree, but define-key allows the KEY argument to be any ASCII string
> > representing a valid sequence of keys or events. How do we
> > "translate" that to 'kbd' syntax? One way is to make key-valid-p be
> > permissive and rely on define-key to signal an error if the key is
> > invalid.
>
> That's not a full solution: (key-parse "<up> <up>") is already defined
> to return [up up], so we need some new syntax to allow it to return
> [up>\ <up] for event names like `up> <up`.
> IOW, we need some escaping mechanism.
>
>
> Stefan
>
>
--
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
"Sagen's Paradeiser" (ORF: Als Radiohören gefährlich war) => write BE!
Year 1 of the New Koprocracy
[Message part 2 (text/html, inline)]
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.