GNU bug report logs - #78582
30.1; which-key-mode overwrites custom key bindings

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: murray.alex <at> gmail.com, luangruo <at> yahoo.com, monnier <at> iro.umontreal.ca, 78582 <at> debbugs.gnu.org
Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Mon, 02 Jun 2025 14:49:43 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  murray.alex <at> gmail.com,
>>>   luangruo <at> yahoo.com,  78582 <at> debbugs.gnu.org
>>> Date: Mon, 02 Jun 2025 10:22:38 +0200
>>> 
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> 
>>> >> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>>> >> Cc: Alex Murray <murray.alex <at> gmail.com>,  Po Lu <luangruo <at> yahoo.com>,
>>> >>   78582 <at> debbugs.gnu.org
>>> >> Date: Mon, 02 Jun 2025 06:24:12 +0200
>>> >> 
>>> >> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>> >> 
>>> >> > I have no idea how to fix this.
>>> >> 
>>> >> In any case, code that changes global state like global-set-key does
>>> >> looks wrong in loaddefs.el.
>>> >
>>> > What's wrong with it?  It's a direct effect of this part of kmacro.el:
>>> >
>>> >   ;;; Provide some binding for startup:
>>> >   ;;;###autoload (global-set-key "\C-x(" #'kmacro-start-macro)
>>> >   ;;;###autoload (global-set-key "\C-x)" #'kmacro-end-macro)
>>> >   ;;;###autoload (global-set-key "\C-xe" #'kmacro-end-and-call-macro)
>>> >   ;;;###autoload (global-set-key [f3] #'kmacro-start-macro-or-insert-counter)
>>> >   ;;;###autoload (global-set-key [f4] #'kmacro-end-or-call-macro)
>>> >   ;;;###autoload (global-set-key "\C-x\C-k" #'kmacro-keymap)
>>> >   ;;;###autoload (autoload 'kmacro-keymap "kmacro" "Keymap for keyboard macro commands." t 'keymap)
>>> >
>>> > IOW, we do this on purpose, for the reasons explained in the comment.
>>> > Given that loaddefs is supposed toe be loaded just once, during
>>> > dumping, why is that wrong?
>>> 
>>> I don't follow. I didn't say it was done unintentionally, and being done
>>> intentionally doesn't mean it's right.
>>
>> Not it general, but please tell what is wrong with the logic I
>> described above that is at work in this particular case.  Are you
>> saying that it is wrong to expect loaddefs not be loaded by a running
>> Emacs session?  If so, please tell why.
>
> AFAICT, the code in Fdocumentation can reload doc strings from files. I
> showed reread_doc_file.
>
> doc.c:
>   310 static void
>   311 reread_doc_file (Lisp_Object file)
>   312 {
>   313   if (NILP (file))
>   314     Fsnarf_documentation (Vdoc_file_name);
>   315   else
>   316     save_match_data_load (file, Qt, Qt, Qt, Qnil);
>   317 }
>
> Secondly, doc strings can point to loaddefs.el
>
>   (function-documentation 'rectangle-mark-mode)
>    => ("loaddefs.elc" . 1059343)
>
> in the Emacs I'm writing this.
>
> Both together mean that loaddefs can be loaded when the path through
> reread_doc_file is taken. Not that I know why it happens, but it does
> happen, as this case demonstrates.
>
> Code that prevents loaddefs specifically from being loaded I can't find.
> Maybe it was just an assumption that this never happens and something
> was changed that made the assumption being wrong? Don't know.

Forgot to mention: kmacro and smerge seem to be the only ones using this
"global-set-key in loaddefs" mechanism.

Previous Next

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