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

Previous Next

To reply to this bug, email your comments to 78582 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Rick <rbielaws <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; which-key-mode overwrites custom key bindings
Date: Sat, 24 May 2025 16:16:23 -0500

[Message part 1 (text/plain, inline)]

|--text follows this line-- ||The problem can't be reproduced with -Q however with -q one only needs 
2 lines in .emacs to recreate. Also, be forewarned that the problem DOES 
NOT happen if you specify --debug-init. This is the only command line 
option I tried and it hampered predictable recreation efforts. .emacs 
content = (global-set-key [f3] 'describe-key) (custom-set-variables 
'(which-key-mode t)) ||Upon startup, quickly type C-h k F3. It shows F3 is bound to describe-key| as expected and the key works
normally as do any others you have set. Try it as much as you like.

Now comes the||insidious part.  If you type the 'k' a little bit too
slowly F3 is overwritten by|kmacro-start-macro-or-insert-counter. Specifically, type C-h and wait 
before typing k. Then F3. Other situations and chords have a similar 
effect but the common thread is that no key combination in particular 
ever causes the problem reliably. It seems to only happen if you use a 
prefix (C-u) or take too long typing the 2nd key in a combination but I 
don't really know. Possibly useful observations: I noticed 2 other 
clobbered keys while troubleshooting F3 but assumed they were related 
and didn't look at them further. I did, however notice they require 
different circumstances from those above to be reset because both 
mouse-1 and M-i were ||reset to defaults independently of F3. That is, I observed an instance 
where M-i was reset but F3 was not. I also saw F3 reset when mouse-2 was 
not.|
|Another useful point is that once a key has been reverted to defaults, 
if you re-assert your preference it will never revert again. I suspect 
--debug-init invokes whatever initially causes the keys to be 
overwritten and site-start is then in the position otherwise occupied by 
someone re-asserting their preferences. If true, it explains how keys 
can 'stick' after a ||--debug-init start. If other things have a similar effect, something 
many users do may limit the number of people experiencing the problem. |||||Or, maybe it's something specific to this build since I've never had a
Ubuntu machine before, my config has never seen a non-Windows build till
now.

|In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, 
cairo version 1.18.0) of 2025-05-11 built on lcy02-amd64-059 Repository 
revision: 9328fd1ab06a1a1f85077fd1caadf9128c90f6c1 Repository branch: 
master System Description: Ubuntu 24.04.2 LTS Configured using: 
'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3 
--without-xaw3d --with-modules --with-cairo 
--with-native-compilation=aot --with-pgtk --with-xinput2 
--with-tree-sitter 'CFLAGS=-isystem 
/build/emacs/parts/emacs/install/usr/include -isystem 
/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem 
/build/emacs/stage/usr/include -O2' 'CPPFLAGS=-isystem 
/build/emacs/parts/emacs/install/usr/include -isystem 
/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem 
/build/emacs/stage/usr/include' 
'LDFLAGS=-L/build/emacs/parts/emacs/install/lib 
-L/build/emacs/parts/emacs/install/usr/lib 
-L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu 
-L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu 
-L/build/emacs/stage/usr/lib'' Configured features: ACL CAIRO DBUS 
FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF 
LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER 
PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS 
TREE_SITTER WEBP XIM GTK3 ZLIB Important settings: value of $LANG: 
en_US.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: 
utf-8-unix Major mode: Fundamental Minor modes in effect: tooltip-mode: 
t global-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 blink-cursor-mode: t 
minibuffer-regexp-mode: t buffer-read-only: 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 message mailcap 
yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache 
epa derived epg rfc6068 epg-config gnus-util time-date mm-decode 
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader 
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils 
shortdoc text-property-search kmacro byte-opt help-fns radix-tree 
site-start comp cl-seq comp-cstr cl-extra help-mode comp-common warnings 
icons subr-x rx gv cl-loaddefs cl-lib bytecomp byte-compile 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 
lcms2 multi-tty move-toolbar make-network-process native-compile emacs) 
Memory information: ((conses 16 123573 16384) (symbols 48 7625 0) 
(strings 32 25412 1713) (string-bytes 1 1761900) (vectors 16 14083) 
(vector-slots 8 177707 11252) (floats 8 85 3) (intervals 56 476 0) 
(buffers 992 12)) |

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rick <rbielaws <at> gmail.com>
Cc: 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Sun, 25 May 2025 09:16:25 +0300

> Date: Sat, 24 May 2025 16:16:23 -0500
> From: Rick <rbielaws <at> gmail.com>
> 
> The problem can't be reproduced with -Q however with -q one only needs
> 2 lines in .emacs to recreate.  Also, be forewarned that the problem 
> DOES NOT happen if you specify --debug-init.  This is the only command 
> line option I tried and it hampered predictable recreation efforts.
> 
> .emacs content =
> 
>     (global-set-key [f3] 'describe-key) 
>     (custom-set-variables '(which-key-mode t))
> 
> Upon startup, quickly type C-h k F3.
> It shows F3 is bound to describe-key as expected and the key works 
> normally as do any others you have set. Try it as much as you like.
> 
> Now comes the insidious part.  If you type the 'k' a little bit too
> slowly F3 is overwritten by kmacro-start-macro-or-insert-counter.
> Specifically, type C-h and wait before typing k.  Then F3.

I cannot reproduce this.  I tried both on GNU/Linux and on MS-Windows,
with Emacs 30.1 and the current master branch (which will be some day
Emacs 31), and I don't see the problem.  But then I don't actually
understand what you mean by "F3 is overwritten by
kmacro-start-macro-or-insert-counter" -- can you describe what you
see?  What I see is the *Help* buffer showing the description of
describe-key, as expected.  And that doesn't change if I type 'k'
immediately or after a delay, the only difference between these two is
that when I wait before typing 'k', Emacs pops up the which-key
display showing the possible keys to type after "C-h".  But once I
type 'k', all the rest is the same regardless.

Are you sure you don't have some early-init or site-start file which
could explain the problem?

Does the problem happen if you start "emacs -Q" and then evaluate
those two lines in *scratch* ?

Can anyone else reproduce this strange problem?

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

From: Rick <rbielaws <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Sun, 25 May 2025 18:19:20 -0500

[Message part 1 (text/plain, inline)]

I was briefly unable to recreate the problem myself today.  It's 
complicated
because I've never had a UNIX type machine so I'm distracted by the 
learning
curve and making platform mistakes.  The problem does exist though.

These are, hopefully, the reasons it didn't work for you.

1) I didn't realize I never used -q.  I edited the wrong .desktop file.  
Using -q
    prevents the two statements that set up the problem from 
executing.  You CAN
    specify --no-site-file but -q or -Q destroy the setup conditions 
and --debug-init
    often prevents the problem from occurring too so don't do that either.

2) I used 'nonincremental-search-forward rather than 'describe-key as 
the example
    function assigned to F3 when I developed the example.  I have no 
idea why using
    'describe-key makes a difference.  In fact, if I use it, the menu 
of possible prefix
    completions never shows up.  Just the mini-buffer prompt with ? if 
I want help.
    Hard to say if this isn't a completely different problem or perhaps 
related.
In any case it seems saver to use 'nonincremental-search-forward .

As I think about the strangeness of the symptoms I can't help but think 
it's
related to how the build loads into memory and something is assuming some
block containing definitions has never loaded when, it not only has 
been, but
it has even been modified.  So the load is really a reload that's 
revering things.
Afterward, it knows it's been loaded and never overwrites that data again.
It's the only thing I can think of that explains why I've never caught it
overwriting the same keys multiple times.


On Sun, May 25, 2025, 1:16 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

    > Date: Sat, 24 May 2025 16:16:23 -0500
    > From: Rick <rbielaws <at> gmail.com>
    >
    > The problem can't be reproduced with -Q however with -q one only
   needs
    > 2 lines in .emacs to recreate.  Also, be forewarned that the problem
    > DOES NOT happen if you specify --debug-init.  This is the only
   command
    > line option I tried and it hampered predictable recreation efforts.
    >
    > .emacs content =
    >
    >     (global-set-key [f3] 'describe-key)
    >     (custom-set-variables '(which-key-mode t))
    >
    > Upon startup, quickly type C-h k F3.
    > It shows F3 is bound to describe-key as expected and the key works
    > normally as do any others you have set. Try it as much as you like.
    >
    > Now comes the insidious part.  If you type the 'k' a little bit too
    > slowly F3 is overwritten by kmacro-start-macro-or-insert-counter.
    > Specifically, type C-h and wait before typing k.  Then F3.

   I cannot reproduce this.  I tried both on GNU/Linux and on MS-Windows,
   with Emacs 30.1 and the current master branch (which will be some day
   Emacs 31), and I don't see the problem.  But then I don't actually
   understand what you mean by "F3 is overwritten by
   kmacro-start-macro-or-insert-counter" -- can you describe what you
   see?  What I see is the *Help* buffer showing the description of
   describe-key, as expected.  And that doesn't change if I type 'k'
   immediately or after a delay, the only difference between these two is
   that when I wait before typing 'k', Emacs pops up the which-key
   display showing the possible keys to type after "C-h".  But once I
   type 'k', all the rest is the same regardless.

   Are you sure you don't have some early-init or site-start file which
   could explain the problem?

   Does the problem happen if you start "emacs -Q" and then evaluate
   those two lines in *scratch* ?

   Can anyone else reproduce this strange problem?

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rick <rbielaws <at> gmail.com>
Cc: 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Mon, 26 May 2025 13:50:05 +0300

> Date: Sun, 25 May 2025 18:19:20 -0500
> From: Rick <rbielaws <at> gmail.com>
> Cc: 78582 <at> debbugs.gnu.org
> 
> 1) I didn't realize I never used -q.  I edited the wrong .desktop file.  Using -q
>     prevents the two statements that set up the problem from executing.  You CAN
>     specify --no-site-file but -q or -Q destroy the setup conditions and --debug-init 
>     often prevents the problem from occurring too so don't do that either.

Sorry, I'm not following.  First, what does the .desktop file have to
do with it?  If it's involved, please explain why; otherwise, let's
not consider unnecessary complications: this issue is complicated even
without that.  AFAIU your recipe, Emacs should not try to load any
.desktop files in this case.

Second, I did try your recipe without -q and without -Q, by using a
.emacs file with those two lines and nothing else.  I couldn't
reproduce the problem.  I asked (among other things) whether you are
able to reproduce by starting "emacs -Q" and then evaluating those
two lines in such a session.  AFAIU, this should be equivalent to your
recipe, and if it turns out it isn't equivalent, we need to consider
what happens during startup.

> 2) I used 'nonincremental-search-forward rather than 'describe-key as the example 
>     function assigned to F3 when I developed the example.  I have no idea why using
>     'describe-key makes a difference.  In fact, if I use it, the menu of possible prefix
>     completions never shows up.  Just the mini-buffer prompt with ? if I want help.
>     Hard to say if this isn't a completely different problem or perhaps related.
> In any case it seems saver to use 'nonincremental-search-forward .

Please show a full recipe using nonincremental-search-forward, and I
will try it.

> As I think about the strangeness of the symptoms I can't help but think it's 
> related to how the build loads into memory and something is assuming some
> block containing definitions has never loaded when, it not only has been, but 
> it has even been modified.  So the load is really a reload that's revering things. 
> Afterward, it knows it's been loaded and never overwrites that data again.
> It's the only thing I can think of that explains why I've never caught it 
> overwriting the same keys multiple times.

I wouldn't go to such lengths without a good reason.  We don't yet
have a reason to assume something this weird happens.

Thanks.

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

From: Rick <rbielaws <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Mon, 26 May 2025 10:36:52 -0500

[Message part 1 (text/plain, inline)]

I confirmed your suggested steps DO produce the problem.

Specifically:  From a terminal enter:  emacs -Q

In the *scratch* buffer that presents paste

(global-set-key [f3] 'nonincremental-repeat-search-forward)
(custom-set-variables '(which-key-mode t))

C-x C-e the lines in presented order.
C-h k f3 quickly and see nonincremental-repeat-search-forward
C-h and wait for the menu before typing k f3
kmacro-start-macro-or-insert-counter is now in the *Help* buffer.

||

On 5/26/25 05:50, Eli Zaretskii wrote:
>> Date: Sun, 25 May 2025 18:19:20 -0500
>> From: Rick<rbielaws <at> gmail.com>
>> Cc:78582 <at> debbugs.gnu.org
>>
>> 1) I didn't realize I never used -q.  I edited the wrong .desktop file.  Using -q
>>      prevents the two statements that set up the problem from executing.  You CAN
>>      specify --no-site-file but -q or -Q destroy the setup conditions and --debug-init
>>      often prevents the problem from occurring too so don't do that either.
> Sorry, I'm not following.  First, what does the .desktop file have to
> do with it?  If it's involved, please explain why; otherwise, let's
> not consider unnecessary complications: this issue is complicated even
> without that.  AFAIU your recipe, Emacs should not try to load any
> .desktop files in this case.
>
> Second, I did try your recipe without -q and without -Q, by using a
> .emacs file with those two lines and nothing else.  I couldn't
> reproduce the problem.  I asked (among other things) whether you are
> able to reproduce by starting "emacs -Q" and then evaluating those
> two lines in such a session.  AFAIU, this should be equivalent to your
> recipe, and if it turns out it isn't equivalent, we need to consider
> what happens during startup.
>
>> 2) I used 'nonincremental-search-forward rather than 'describe-key as the example
>>      function assigned to F3 when I developed the example.  I have no idea why using
>>      'describe-key makes a difference.  In fact, if I use it, the menu of possible prefix
>>      completions never shows up.  Just the mini-buffer prompt with ? if I want help.
>>      Hard to say if this isn't a completely different problem or perhaps related.
>> In any case it seems saver to use 'nonincremental-search-forward .
> Please show a full recipe using nonincremental-search-forward, and I
> will try it.
>
>> As I think about the strangeness of the symptoms I can't help but think it's
>> related to how the build loads into memory and something is assuming some
>> block containing definitions has never loaded when, it not only has been, but
>> it has even been modified.  So the load is really a reload that's revering things.
>> Afterward, it knows it's been loaded and never overwrites that data again.
>> It's the only thing I can think of that explains why I've never caught it
>> overwriting the same keys multiple times.
> I wouldn't go to such lengths without a good reason.  We don't yet
> have a reason to assume something this weird happens.
>
> Thanks.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rick <rbielaws <at> gmail.com>
Cc: 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Mon, 26 May 2025 19:21:08 +0300

> Date: Mon, 26 May 2025 10:36:52 -0500
> Cc: 78582 <at> debbugs.gnu.org
> From: Rick <rbielaws <at> gmail.com>
> 
> I confirmed your suggested steps DO produce the problem.
> 
> Specifically:  From a terminal enter:  emacs -Q
> 
> In the *scratch* buffer that presents paste
> 
> (global-set-key [f3] 'nonincremental-repeat-search-forward)
> (custom-set-variables '(which-key-mode t))
> 
> C-x C-e the lines in presented order.
> C-h k f3 quickly and see nonincremental-repeat-search-forward
> C-h and wait for the menu before typing k f3  
> kmacro-start-macro-or-insert-counter is now in the *Help* buffer.

Thanks.  This doesn't reproduce the problem on my system.

So now I suspect that your Emacs has some local changes that are not
in upstream.  Is that possible?  Your build details:

  In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,
   cairo version 1.18.0) of 2025-05-11 built on lcy02-amd64-059
  Repository revision: 9328fd1ab06a1a1f85077fd1caadf9128c90f6c1
  Repository branch: master
  System Description: Ubuntu 24.04.2 LTS

are strange: on the one hand this says version 30.1, but OTOH the
branch is 'master' (which is not the branch from which Emacs 30.1 was
delivered), and the commit SHA is not a commit our Git repository
knows about.  What repository did you use to build, and could it be
that it has some local changes?

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

From: Rick <rbielaws <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Mon, 26 May 2025 12:23:42 -0500

I used App Center on this Ubuntu machine to find and install Emacs via Snap.

The Snap description includes this:

This snap is built via the build.snapcraft.io service from the 
snapcraft.yaml definition at https://github.com/alexmurray/emacs-snap to 
ensure source and build transparency.

They make no mention of anything custom on their site.
Since neither you nor several people on StackExchange can recreate the 
problem, I will report the issue to the build maintainer on GitHub.


On 5/26/25 11:21, Eli Zaretskii wrote:
>> Date: Mon, 26 May 2025 10:36:52 -0500
>> Cc: 78582 <at> debbugs.gnu.org
>> From: Rick <rbielaws <at> gmail.com>
>>
>> I confirmed your suggested steps DO produce the problem.
>>
>> Specifically:  From a terminal enter:  emacs -Q
>>
>> In the *scratch* buffer that presents paste
>>
>> (global-set-key [f3] 'nonincremental-repeat-search-forward)
>> (custom-set-variables '(which-key-mode t))
>>
>> C-x C-e the lines in presented order.
>> C-h k f3 quickly and see nonincremental-repeat-search-forward
>> C-h and wait for the menu before typing k f3
>> kmacro-start-macro-or-insert-counter is now in the *Help* buffer.
> Thanks.  This doesn't reproduce the problem on my system.
>
> So now I suspect that your Emacs has some local changes that are not
> in upstream.  Is that possible?  Your build details:
>
>    In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,
>     cairo version 1.18.0) of 2025-05-11 built on lcy02-amd64-059
>    Repository revision: 9328fd1ab06a1a1f85077fd1caadf9128c90f6c1
>    Repository branch: master
>    System Description: Ubuntu 24.04.2 LTS
>
> are strange: on the one hand this says version 30.1, but OTOH the
> branch is 'master' (which is not the branch from which Emacs 30.1 was
> delivered), and the commit SHA is not a commit our Git repository
> knows about.  What repository did you use to build, and could it be
> that it has some local changes?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rick <rbielaws <at> gmail.com>
Cc: 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Mon, 26 May 2025 21:32:51 +0300

> Date: Mon, 26 May 2025 12:23:42 -0500
> Cc: 78582 <at> debbugs.gnu.org
> From: Rick <rbielaws <at> gmail.com>
> 
> I used App Center on this Ubuntu machine to find and install Emacs via Snap.
> 
> The Snap description includes this:
> 
> This snap is built via the build.snapcraft.io service from the 
> snapcraft.yaml definition at https://github.com/alexmurray/emacs-snap to 
> ensure source and build transparency.
> 
> They make no mention of anything custom on their site.
> Since neither you nor several people on StackExchange can recreate the 
> problem, I will report the issue to the build maintainer on GitHub.

Thanks.  Please ask them whether they have any local changes wrt the
upstream Git repository, and also on what revision of the upstream
repository is the version you have based.

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

From: Alex Murray <murray.alex <at> gmail.com>
To: eliz <at> gnu.org, bug-gnu-emacs <at> gnu.org
Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Tue, 27 May 2025 10:28:36 +0930

Hi folks

Upstream maintainer of emacs-snap here.

I have just had this issue brought to my attention via
https://github.com/alexmurray/emacs-snap/issues/106 - thanks Rick.

To provide some more context - the emacs-snap carries a few
customisations to work around issues with the nature of the snap
execution environment and to try and ensure the correct library paths
etc are used in various places (since a snap is designed to operate on
any given Linux system, not just the one it was compiled on).

These are achieved by a mix of some site-lisp and some patches to the
source code directly and a short C program that runs before the emacs
binary itself is executed to ensure things like the GTK environment
and fonts etc are all respected from the users machine.

All of these are maintained at
https://github.com/alexmurray/emacs-snap/ - you will see a small C
program, 3 different patch files and the site-lisp which can be
summarised as follows:

setup-env is the small C program to set the GTK environment and other
associated bits etc to ensure that the emacs snap respects the host
systems GTK settings etc (even if it is a different GTK version etc)
and which then exec's the emacs binary itself

native-comp.patch - to ensure native-comp uses the compiler that the
emacs snap itself was compiled with rather than the one on the host
system
treesit.patch - similarly, to ensure when compiling tree-sitter
modules that they use the same compiler and libc etc as the emacs-snap
itself uses
emacs-x-resource-name.patch - always set the x resource name to
"emacs" to ensure that GNOME can associate the process with the right
desktop file

The site-lisp bit just unsets some environment variables that got set
by the setup-env program to ensure that any process that the
emacs-snap executes doesn't get confused about the environment it is
running in (since in general these will need to use the host systems
settings, not the ones from the emacs-snap).

On the surface of it, none of these changes would appear to me to be
causing this issue, however clearly there is a bug here that only
affects the emacs snap so I am quite keen to try and resolve it.

However, whilst I can reproduce it using the instructions provided by
Rick I am at a bit of a loss as to what to do next to try and debug it
- if anyone can give any hints or ideas that would be greatly
appreciated.

Thanks,
Alex

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex Murray <murray.alex <at> gmail.com>
Cc: 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Tue, 27 May 2025 14:20:23 +0300

> From: Alex Murray <murray.alex <at> gmail.com>
> Date: Tue, 27 May 2025 10:28:36 +0930
> 
> Hi folks
> 
> Upstream maintainer of emacs-snap here.
> 
> I have just had this issue brought to my attention via
> https://github.com/alexmurray/emacs-snap/issues/106 - thanks Rick.
> 
> To provide some more context - the emacs-snap carries a few
> customisations to work around issues with the nature of the snap
> execution environment and to try and ensure the correct library paths
> etc are used in various places (since a snap is designed to operate on
> any given Linux system, not just the one it was compiled on).
> 
> These are achieved by a mix of some site-lisp and some patches to the
> source code directly and a short C program that runs before the emacs
> binary itself is executed to ensure things like the GTK environment
> and fonts etc are all respected from the users machine.
> 
> All of these are maintained at
> https://github.com/alexmurray/emacs-snap/ - you will see a small C
> program, 3 different patch files and the site-lisp which can be
> summarised as follows:
> 
> setup-env is the small C program to set the GTK environment and other
> associated bits etc to ensure that the emacs snap respects the host
> systems GTK settings etc (even if it is a different GTK version etc)
> and which then exec's the emacs binary itself
> 
> native-comp.patch - to ensure native-comp uses the compiler that the
> emacs snap itself was compiled with rather than the one on the host
> system
> treesit.patch - similarly, to ensure when compiling tree-sitter
> modules that they use the same compiler and libc etc as the emacs-snap
> itself uses
> emacs-x-resource-name.patch - always set the x resource name to
> "emacs" to ensure that GNOME can associate the process with the right
> desktop file
> 
> The site-lisp bit just unsets some environment variables that got set
> by the setup-env program to ensure that any process that the
> emacs-snap executes doesn't get confused about the environment it is
> running in (since in general these will need to use the host systems
> settings, not the ones from the emacs-snap).
> 
> On the surface of it, none of these changes would appear to me to be
> causing this issue, however clearly there is a bug here that only
> affects the emacs snap so I am quite keen to try and resolve it.
> 
> However, whilst I can reproduce it using the instructions provided by
> Rick I am at a bit of a loss as to what to do next to try and debug it
> - if anyone can give any hints or ideas that would be greatly
> appreciated.

Thanks for reaching out.

Can you tell when you last synced with the upstream Git repository,
and with which branch?  Looking at your latest commits, it seems the
answer is Feb 24 and emacs-30, respectively, but is that correct?

If you build the upstream version of Emacs without your local changes,
do you still see the problem with Rick's recipe?

If the upstream build still shows the problem, I'd say take a look at
your build environment, including libraries and the toolkit you use.
The command "C-h l" should show the keys read by Emacs, so maybe try
that in both scenarios to see what Emacs saw as keyboard input.

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

From: Alex Murray <murray.alex <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Tue, 27 May 2025 21:09:54 +0930

Hi Eli,

On Tue, 27 May 2025 at 20:50, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>
> Thanks for reaching out.
>
> Can you tell when you last synced with the upstream Git repository,
> and with which branch?  Looking at your latest commits, it seems the
> answer is Feb 24 and emacs-30, respectively, but is that correct?
>

The stable channel of the emacs snap builds from the 30.1 release
tarbal l- https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L64

> If you build the upstream version of Emacs without your local changes,
> do you still see the problem with Rick's recipe?
>
> If the upstream build still shows the problem, I'd say take a look at
> your build environment, including libraries and the toolkit you use.
> The command "C-h l" should show the keys read by Emacs, so maybe try
> that in both scenarios to see what Emacs saw as keyboard input.

Your hint about toolkit got me interested - for a bit more info on the
emacs snap, I build emacs both with pgtk
(https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L296)
and without it (https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L314)
and then bundle both inside the snap and use a script to try and
choose the most appropriate one to use at runtime.

If I force it to use the gtk variant (ie. non-pgtk) then I can no
longer reproduce this issue with the emacs snap. However I am able to
reproduce it with the pgtk variant.

Could it be an issue with pgtk specifically and not the emacs snap perse?

Thanks,
Alex

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex Murray <murray.alex <at> gmail.com>, Po Lu <luangruo <at> yahoo.com>
Cc: 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Tue, 27 May 2025 15:07:37 +0300

> From: Alex Murray <murray.alex <at> gmail.com>
> Date: Tue, 27 May 2025 21:09:54 +0930
> Cc: 78582 <at> debbugs.gnu.org
> 
> Your hint about toolkit got me interested - for a bit more info on the
> emacs snap, I build emacs both with pgtk
> (https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L296)
> and without it (https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L314)
> and then bundle both inside the snap and use a script to try and
> choose the most appropriate one to use at runtime.
> 
> If I force it to use the gtk variant (ie. non-pgtk) then I can no
> longer reproduce this issue with the emacs snap. However I am able to
> reproduce it with the pgtk variant.
> 
> Could it be an issue with pgtk specifically and not the emacs snap perse?

Could be.  Would people who use PGTK please try reproducing the issue
with the recipe and report?

Po Lu, any ideas why the PGTK build could show this strange behavior?

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

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

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Alex Murray <murray.alex <at> gmail.com>
>> Date: Tue, 27 May 2025 21:09:54 +0930
>> Cc: 78582 <at> debbugs.gnu.org
>> 
>> Your hint about toolkit got me interested - for a bit more info on the
>> emacs snap, I build emacs both with pgtk
>> (https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L296)
>> and without it (https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L314)
>> and then bundle both inside the snap and use a script to try and
>> choose the most appropriate one to use at runtime.
>> 
>> If I force it to use the gtk variant (ie. non-pgtk) then I can no
>> longer reproduce this issue with the emacs snap. However I am able to
>> reproduce it with the pgtk variant.
>> 
>> Could it be an issue with pgtk specifically and not the emacs snap perse?
>
> Could be.  Would people who use PGTK please try reproducing the issue
> with the recipe and report?
>
> Po Lu, any ideas why the PGTK build could show this strange behavior?

I encountered this on macOS today. Reproducer with an installed Emacs 
(which is the Emacs.app on macOS):

  ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q

In *scratch*, eval

 (global-set-key [f4] #'kill-current-buffer)
 (documentation 'rectangle-mark-mode)

Then C-h k <f4> and observe that it has been redefined.

A backtrace how this happens with which-key is at then end. In short,
which-key calls 'documentation' which loads lisp/loaddefs which
evaluates the global-set-keys loaddefs.el contains.

I have no idea how to fix this.


  global-set-key("\30(" kmacro-start-macro)
  byte-code("\300\301\302\303\304$\210\305\302\306\"\210\307\310\311\"\210\307\312\313\"\210\307\314\315\"\210\307\316\317\"\210\307\320\321\"\210\307\322\323\"\210\300\323\324\325\304\326%\210\327\330\331\332#\210\333\330\331\334#\210\300\311\324\335\304$\210\300\313\324\336\304$\210\300\337\324\340\304$\210\300\317\324\341\304$\210\300\321\324\342\304$\210\300\315\324\343\304$\210\300\344\324\345\304$\210\300\346\324\347#\210\300\350\324\351#\210\333\350\346\334#\210\300\352\324\353\304$\210\327\354\355\"\210\300\355\324\356\304$\210\305\324\357\"\207" [autoload kkc-region "kkc" ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 768162) t register-definition-prefixes ("kkc-") global-set-key "\30(" kmacro-start-macro "\30)" kmacro-end-macro "\30e" kmacro-end-and-call-macro [f3] kmacro-start-macro-or-insert-counter [f4] kmacro-end-or-call-macro "\30\13" kmacro-keymap "kmacro" ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 768555) keymap defalias kmacro-exec-ring-item funcall "Execute item ITEM from the macro ring.\nARG is the number of times to execute the item." make-obsolete "29.1" ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 768689) ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 769692) kmacro-call-macro ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 770110) ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 770706) ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 771651) ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 771871) kmacro-end-call-mouse ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 772193) kmacro ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 772352) kmacro-lambda-form ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 772507) kmacro-name-last-macro ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 772549) kmacro-menu list-keyboard-macros ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 772804) ("kmacro-")] 6)
  documentation(rectangle-mark-mode)
  which-key--propertize-description("rectangle-mark-mode" nil nil nil "rectangle-mark-mode")
  which-key--format-and-replace((("C-x DEL" . "backward-kill-sentence") ("C-x ESC ESC" . "repeat-complex-command") ("C-x RET" . "prefix") ("C-x SPC" . "rectangle-mark-mode") ("C-x TAB" . "indent-rigidly") ("C-x #" . "server-edit") ("C-x $" . "set-selective-display") ("C-x '" . "expand-abbrev") ("C-x (" . "kmacro-start-macro") ("C-x )" . "kmacro-end-macro") ("C-x *" . "calc-dispatch") ("C-x +" . "balance-windows") ("C-x -" . "shrink-window-if-larger-than-buffer") ("C-x ." . "set-fill-prefix") ("C-x 0" . "delete-window") ("C-x 1" . "delete-other-windows") ("C-x 2" . "split-window-below") ("C-x 3" . "split-window-right") ("C-x 4" . "ctl-x-4-prefix") ("C-x 5" . "ctl-x-5-prefix") ("C-x 8" . "prefix") ("C-x ;" . "comment-set-column") ("C-x <" . "scroll-left") ("C-x =" . "what-cursor-position") ("C-x >" . "scroll-right") ("C-x X" . "prefix") ("C-x [" . "backward-page") ("C-x \\" . "activate-transient-input-method") ("C-x ]" . "forward-page") ("C-x ^" . "enlarge-window") ("C-x `" . "next-error") ("C-x a" . "prefix") ("C-x b" . "consult-buffer") ("C-x d" . "dired") ("C-x e" . "kmacro-end-and-call-macro") ("C-x f" . "set-fill-column") ("C-x g" . "magit-status-quick") ("C-x h" . "mark-whole-buffer") ("C-x i" . "insert-file") ("C-x k" . "kill-buffer") ("C-x l" . "count-lines-page") ("C-x m" . "compose-mail") ("C-x n" . "prefix") ("C-x o" . "other-window") ("C-x p" . "prefix") ("C-x q" . "kbd-macro-query") ("C-x r" . "prefix") ("C-x s" . "save-some-buffers") ("C-x t" . "prefix") ("C-x u" . "vundo") ...) nil)
  which-key--get-bindings([24] nil nil)
  which-key--create-buffer-and-show([24])
  which-key--update()
  apply(which-key--update nil)
  timer-event-handler([t 0 1 0 t which-key--update nil idle 0 nil])

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Alex Murray <murray.alex <at> gmail.com>, Po Lu <luangruo <at> yahoo.com>,
 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
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.

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

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

> 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 05:49:14 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Po Lu, any ideas why the PGTK build could show this strange behavior?
> 
> I encountered this on macOS today. Reproducer with an installed Emacs 
> (which is the Emacs.app on macOS):
> 
>   ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q
> 
> In *scratch*, eval
> 
>  (global-set-key [f4] #'kill-current-buffer)
>  (documentation 'rectangle-mark-mode)
> 
> Then C-h k <f4> and observe that it has been redefined.

Not reproducible on my system with today's master branch.  When I
press "C-h k <f4>" after evaluating the above line by line, I get the
expected documentation of kill-current-buffer.

> A backtrace how this happens with which-key is at then end. In short,
> which-key calls 'documentation' which loads lisp/loaddefs which
> evaluates the global-set-keys loaddefs.el contains.

"M-x debug-on-entry RET global-set-key RET" doesn't pop up the
debugger when I evaluate "(documentation 'rectangle-mark-mode)".

Anyway, why would Emacs want to load loaddefs, when loaddefs is
preloaded?

> I have no idea how to fix this.

And I have no idea why this happens on some systems, but not on
others.

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

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

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

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

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,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Mon, 02 Jun 2025 09:42:17 +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 05:49:14 +0200
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Po Lu, any ideas why the PGTK build could show this strange behavior?
>> 
>> I encountered this on macOS today. Reproducer with an installed Emacs 
>> (which is the Emacs.app on macOS):
>> 
>>   ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q
>> 
>> In *scratch*, eval
>> 
>>  (global-set-key [f4] #'kill-current-buffer)
>>  (documentation 'rectangle-mark-mode)
>> 
>> Then C-h k <f4> and observe that it has been redefined.
>
> Not reproducible on my system with today's master branch.  When I
> press "C-h k <f4>" after evaluating the above line by line, I get the
> expected documentation of kill-current-buffer.

It seems to depend on trying this in an installed Emacs, and that that
Emacs is older than what is built in the repo that I built it in. For
example, the Emacs I'm running is from some weeks ago when I started
using the NS freeze workaround I posted to emacs-devel. In the repo, a
more current Emacs is built.

>> A backtrace how this happens with which-key is at then end. In short,
>> which-key calls 'documentation' which loads lisp/loaddefs which
>> evaluates the global-set-keys loaddefs.el contains.
>
> "M-x debug-on-entry RET global-set-key RET" doesn't pop up the
> debugger when I evaluate "(documentation 'rectangle-mark-mode)".
>
> Anyway, why would Emacs want to load loaddefs, when loaddefs is
> preloaded?

Could be Fdocumentation:

doc.c:
  365   if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc))))
  366     {
  367       Lisp_Object tem = get_doc_string (doc, 0);
  368       if (NILP (tem) && try_reload)
  369         {
  370           /* The file is newer, we need to reset the pointers.  */
  371           reread_doc_file (Fcar_safe (doc));
  372           try_reload = false;


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 }

That's of course not the root cause, but somehow it's happening.

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

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

> 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 09:42:17 +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 05:49:14 +0200
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> > Po Lu, any ideas why the PGTK build could show this strange behavior?
> >> 
> >> I encountered this on macOS today. Reproducer with an installed Emacs 
> >> (which is the Emacs.app on macOS):
> >> 
> >>   ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q
> >> 
> >> In *scratch*, eval
> >> 
> >>  (global-set-key [f4] #'kill-current-buffer)
> >>  (documentation 'rectangle-mark-mode)
> >> 
> >> Then C-h k <f4> and observe that it has been redefined.
> >
> > Not reproducible on my system with today's master branch.  When I
> > press "C-h k <f4>" after evaluating the above line by line, I get the
> > expected documentation of kill-current-buffer.
> 
> It seems to depend on trying this in an installed Emacs, and that that
> Emacs is older than what is built in the repo that I built it in. For
> example, the Emacs I'm running is from some weeks ago when I started
> using the NS freeze workaround I posted to emacs-devel. In the repo, a
> more current Emacs is built.
> 
> >> A backtrace how this happens with which-key is at then end. In short,
> >> which-key calls 'documentation' which loads lisp/loaddefs which
> >> evaluates the global-set-keys loaddefs.el contains.
> >
> > "M-x debug-on-entry RET global-set-key RET" doesn't pop up the
> > debugger when I evaluate "(documentation 'rectangle-mark-mode)".
> >
> > Anyway, why would Emacs want to load loaddefs, when loaddefs is
> > preloaded?
> 
> Could be Fdocumentation:
> 
> doc.c:
>   365   if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc))))
>   366     {
>   367       Lisp_Object tem = get_doc_string (doc, 0);
>   368       if (NILP (tem) && try_reload)
>   369         {
>   370           /* The file is newer, we need to reset the pointers.  */
>   371           reread_doc_file (Fcar_safe (doc));
>   372           try_reload = false;
> 
> 
> 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 }
> 
> That's of course not the root cause, but somehow it's happening.

So you are saying that the problem happens if Emacs is older than its
loaddefs.el?  If so, this is not a situation we support, so I think
this bug is not a bug at all.  When loaddefs is regenerated, one is
supposed to re-dump Emacs.

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

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: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Mon, 02 Jun 2025 10:20:25 +0200

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 09:42:17 +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 05:49:14 +0200
>> >> 
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> 
>> >> > Po Lu, any ideas why the PGTK build could show this strange behavior?
>> >> 
>> >> I encountered this on macOS today. Reproducer with an installed Emacs 
>> >> (which is the Emacs.app on macOS):
>> >> 
>> >>   ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q
>> >> 
>> >> In *scratch*, eval
>> >> 
>> >>  (global-set-key [f4] #'kill-current-buffer)
>> >>  (documentation 'rectangle-mark-mode)
>> >> 
>> >> Then C-h k <f4> and observe that it has been redefined.
>> >
>> > Not reproducible on my system with today's master branch.  When I
>> > press "C-h k <f4>" after evaluating the above line by line, I get the
>> > expected documentation of kill-current-buffer.
>> 
>> It seems to depend on trying this in an installed Emacs, and that that
>> Emacs is older than what is built in the repo that I built it in. For
>> example, the Emacs I'm running is from some weeks ago when I started
>> using the NS freeze workaround I posted to emacs-devel. In the repo, a
>> more current Emacs is built.
>> 
>> >> A backtrace how this happens with which-key is at then end. In short,
>> >> which-key calls 'documentation' which loads lisp/loaddefs which
>> >> evaluates the global-set-keys loaddefs.el contains.
>> >
>> > "M-x debug-on-entry RET global-set-key RET" doesn't pop up the
>> > debugger when I evaluate "(documentation 'rectangle-mark-mode)".
>> >
>> > Anyway, why would Emacs want to load loaddefs, when loaddefs is
>> > preloaded?
>> 
>> Could be Fdocumentation:
>> 
>> doc.c:
>>   365   if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc))))
>>   366     {
>>   367       Lisp_Object tem = get_doc_string (doc, 0);
>>   368       if (NILP (tem) && try_reload)
>>   369         {
>>   370           /* The file is newer, we need to reset the pointers.  */
>>   371           reread_doc_file (Fcar_safe (doc));
>>   372           try_reload = false;
>> 
>> 
>> 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 }
>> 
>> That's of course not the root cause, but somehow it's happening.
>
> So you are saying that the problem happens if Emacs is older than its
> loaddefs.el?  If so, this is not a situation we support, so I think
> this bug is not a bug at all.  When loaddefs is regenerated, one is
> supposed to re-dump Emacs.

No that doesn't seem to be the case. In the installed Emacs.app

  /Users/gerd/Desktop/Emacs.app/Contents/MacOS:
  -rwxr-xr-x 1 gerd staff 4678640 Jun  1 04:55 Emacs

  -rw-r--r--   1 gerd staff  396932 Jun  1 04:55 loaddefs.el.gz
  -rw-r--r--   1 gerd staff 1530577 Jun  1 04:55 loaddefs.elc

  -rw-r--r--   1 gerd staff 991796 Jun  1 04:56 DOC

The timestamps look okay.

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

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,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
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.

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

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

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 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:20:25 +0200
> 
> 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 09:42:17 +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 05:49:14 +0200
> >> >> 
> >> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> >> 
> >> >> > Po Lu, any ideas why the PGTK build could show this strange behavior?
> >> >> 
> >> >> I encountered this on macOS today. Reproducer with an installed Emacs 
> >> >> (which is the Emacs.app on macOS):
> >> >> 
> >> >>   ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q
> >> >> 
> >> >> In *scratch*, eval
> >> >> 
> >> >>  (global-set-key [f4] #'kill-current-buffer)
> >> >>  (documentation 'rectangle-mark-mode)
> >> >> 
> >> >> Then C-h k <f4> and observe that it has been redefined.
> >> >
> >> > Not reproducible on my system with today's master branch.  When I
> >> > press "C-h k <f4>" after evaluating the above line by line, I get the
> >> > expected documentation of kill-current-buffer.
> >> 
> >> It seems to depend on trying this in an installed Emacs, and that that
> >> Emacs is older than what is built in the repo that I built it in. For
> >> example, the Emacs I'm running is from some weeks ago when I started
> >> using the NS freeze workaround I posted to emacs-devel. In the repo, a
> >> more current Emacs is built.
> >> 
> >> >> A backtrace how this happens with which-key is at then end. In short,
> >> >> which-key calls 'documentation' which loads lisp/loaddefs which
> >> >> evaluates the global-set-keys loaddefs.el contains.
> >> >
> >> > "M-x debug-on-entry RET global-set-key RET" doesn't pop up the
> >> > debugger when I evaluate "(documentation 'rectangle-mark-mode)".
> >> >
> >> > Anyway, why would Emacs want to load loaddefs, when loaddefs is
> >> > preloaded?
> >> 
> >> Could be Fdocumentation:
> >> 
> >> doc.c:
> >>   365   if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc))))
> >>   366     {
> >>   367       Lisp_Object tem = get_doc_string (doc, 0);
> >>   368       if (NILP (tem) && try_reload)
> >>   369         {
> >>   370           /* The file is newer, we need to reset the pointers.  */
> >>   371           reread_doc_file (Fcar_safe (doc));
> >>   372           try_reload = false;
> >> 
> >> 
> >> 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 }
> >> 
> >> That's of course not the root cause, but somehow it's happening.
> >
> > So you are saying that the problem happens if Emacs is older than its
> > loaddefs.el?  If so, this is not a situation we support, so I think
> > this bug is not a bug at all.  When loaddefs is regenerated, one is
> > supposed to re-dump Emacs.
> 
> No that doesn't seem to be the case. In the installed Emacs.app
> 
>   /Users/gerd/Desktop/Emacs.app/Contents/MacOS:
>   -rwxr-xr-x 1 gerd staff 4678640 Jun  1 04:55 Emacs
> 
>   -rw-r--r--   1 gerd staff  396932 Jun  1 04:55 loaddefs.el.gz
>   -rw-r--r--   1 gerd staff 1530577 Jun  1 04:55 loaddefs.elc
> 
>   -rw-r--r--   1 gerd staff 991796 Jun  1 04:56 DOC
> 
> The timestamps look okay.

But you seemed to be saying that the installed Emacs was for some
reason loading loaddefs from the repo's worktree, which was newer:

>> It seems to depend on trying this in an installed Emacs, and that that
>> Emacs is older than what is built in the repo that I built it in. For
>> example, the Emacs I'm running is from some weeks ago when I started
>> using the NS freeze workaround I posted to emacs-devel. In the repo, a
>> more current Emacs is built.

Did I misunderstand?  My point is that if Emacs for some reason loads
a newer loaddefs, that is not a situation that is expected.  maybe we
should understand why that newer loaddefs is being loaded in your
case.

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

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

> 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.

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

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: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Mon, 02 Jun 2025 14:30:29 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: 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:20:25 +0200
>> 
>> 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 09:42:17 +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 05:49:14 +0200
>> >> >> 
>> >> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> >> 
>> >> >> > Po Lu, any ideas why the PGTK build could show this strange behavior?
>> >> >> 
>> >> >> I encountered this on macOS today. Reproducer with an installed Emacs 
>> >> >> (which is the Emacs.app on macOS):
>> >> >> 
>> >> >>   ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q
>> >> >> 
>> >> >> In *scratch*, eval
>> >> >> 
>> >> >>  (global-set-key [f4] #'kill-current-buffer)
>> >> >>  (documentation 'rectangle-mark-mode)
>> >> >> 
>> >> >> Then C-h k <f4> and observe that it has been redefined.
>> >> >
>> >> > Not reproducible on my system with today's master branch.  When I
>> >> > press "C-h k <f4>" after evaluating the above line by line, I get the
>> >> > expected documentation of kill-current-buffer.
>> >> 
>> >> It seems to depend on trying this in an installed Emacs, and that that
>> >> Emacs is older than what is built in the repo that I built it in. For
>> >> example, the Emacs I'm running is from some weeks ago when I started
>> >> using the NS freeze workaround I posted to emacs-devel. In the repo, a
>> >> more current Emacs is built.
>> >> 
>> >> >> A backtrace how this happens with which-key is at then end. In short,
>> >> >> which-key calls 'documentation' which loads lisp/loaddefs which
>> >> >> evaluates the global-set-keys loaddefs.el contains.
>> >> >
>> >> > "M-x debug-on-entry RET global-set-key RET" doesn't pop up the
>> >> > debugger when I evaluate "(documentation 'rectangle-mark-mode)".
>> >> >
>> >> > Anyway, why would Emacs want to load loaddefs, when loaddefs is
>> >> > preloaded?
>> >> 
>> >> Could be Fdocumentation:
>> >> 
>> >> doc.c:
>> >>   365   if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc))))
>> >>   366     {
>> >>   367       Lisp_Object tem = get_doc_string (doc, 0);
>> >>   368       if (NILP (tem) && try_reload)
>> >>   369         {
>> >>   370           /* The file is newer, we need to reset the pointers.  */
>> >>   371           reread_doc_file (Fcar_safe (doc));
>> >>   372           try_reload = false;
>> >> 
>> >> 
>> >> 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 }
>> >> 
>> >> That's of course not the root cause, but somehow it's happening.
>> >
>> > So you are saying that the problem happens if Emacs is older than its
>> > loaddefs.el?  If so, this is not a situation we support, so I think
>> > this bug is not a bug at all.  When loaddefs is regenerated, one is
>> > supposed to re-dump Emacs.
>> 
>> No that doesn't seem to be the case. In the installed Emacs.app
>> 
>>   /Users/gerd/Desktop/Emacs.app/Contents/MacOS:
>>   -rwxr-xr-x 1 gerd staff 4678640 Jun  1 04:55 Emacs
>> 
>>   -rw-r--r--   1 gerd staff  396932 Jun  1 04:55 loaddefs.el.gz
>>   -rw-r--r--   1 gerd staff 1530577 Jun  1 04:55 loaddefs.elc
>> 
>>   -rw-r--r--   1 gerd staff 991796 Jun  1 04:56 DOC
>> 
>> The timestamps look okay.
>
> But you seemed to be saying that the installed Emacs was for some
> reason loading loaddefs from the repo's worktree, which was newer:

I believe it's loading the loaddefs.el from the installation because of
this part of the backtrace I sent in the first mail

  global-set-key("\30(" kmacro-start-macro)
  byte-code("\300\301\302\303\304$\210\305\302\306\"\210\307\310\311\"\210\307\312\313\"\210\307\314\315\"\210\307\316\317\"\210\307\320\321\"\210\307\322\323\"\210\300\323\324\325\304\326%\210\327\330\331\332#\210\333\330\331\334#\210\300\311\324\335\304$\210\300\313\324\336\304$\210\300\337\324\340\304$\210\300\317\324\341\304$\210\300\321\324\342\304$\210\300\315\324\343\304$\210\300\344\324\345\304$\210\300\346\324\347#\210\300\350\324\351#\210\333\350\346\334#\210\300\352\324\353\304$\210\327\354\355\"\210\300\355\324\356\304$\210\305\324\357\"\207" [autoload kkc-region "kkc" ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 768162) t register-definition-prefixes ("kkc-") global-set-key "\30(" kmacro-start-macro "\30)" kmacro-end-macro "\30e" kmacro-end-and-call-macro [f3] kmacro-start-macro-or-insert-counter [f4] kmacro-end-or-call-macro "\30\13" kmacro-keymap "kmacro" ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 768555) keymap defalias kmacro-exec-ring-item funcall "Execute item ITEM from the macro ring.\nARG is the number of times to execute the item." make-obsolete "29.1" ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 768689) ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 769692) kmacro-call-macro ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 770110) ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 770706) ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 771651) ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 771871) kmacro-end-call-mouse ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 772193) kmacro ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 772352) kmacro-lambda-form ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 772507) kmacro-name-last-macro ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 772549) kmacro-menu list-keyboard-macros ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 772804) ("kmacro-")] 6)
  documentation(rectangle-mark-mode)

which mentions the file. No way to be 100% sure though, and it's not
a debug build, so I can't look.

>
>>> It seems to depend on trying this in an installed Emacs, and that that
>>> Emacs is older than what is built in the repo that I built it in. For
>>> example, the Emacs I'm running is from some weeks ago when I started
>>> using the NS freeze workaround I posted to emacs-devel. In the repo, a
>>> more current Emacs is built.
>
> Did I misunderstand?  My point is that if Emacs for some reason loads
> a newer loaddefs, that is not a situation that is expected.  maybe we
> should understand why that newer loaddefs is being loaded in your
> case.

I don't know what's going on either. When I build a new Emacs.app and
run that (even from the sasme commit ID), the problem does not occur.
When I start the older Emacs.app it does 🤷. Without debug info and
having it in LLDB, it's all guess work.

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

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: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Mon, 02 Jun 2025 14:46:53 +0200

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.

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

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: Re: 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.

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

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

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

AFAICT the problem you describe is not specific to `loaddefs.el`.
The same thing can happen with any file that has a `global-set-key` call
at top-level.

This reloading business is supposed to happen only if the in-memory
doc-string-reference is out-of-sync with the installed files, presumably
because you're running Emacs "in place" and the files have changed in
the mean time.

If that's indeed your situation, then "all is well": the problem you're
seeing is "on purpose".  You can fix it by removing the above reloading
mechanism (in exchange for being unable to see the docstring in those
cases where the reloading would be needed).

I tend to see this every once in a while where `C-x C-c` (which
I normally rebind to a less-drastic operation) gets redefined
to its default binding because `files.elc` gets reloaded.  🙂

Maybe we should try and work harder to make such reloading more harmless
(e.g. replace the `define-key/global-set-key`s with functions which do
nothing if the key is already bound?), but it's an issue that affects
only those people who hack on the code of the very Emacs they're
running, so it's not super-high priority.


        Stefan

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

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

>>>>> On Mon, 02 Jun 2025 10:11:16 -0400, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> said:

    Stefan> Maybe we should try and work harder to make such reloading more harmless
    Stefan> (e.g. replace the `define-key/global-set-key`s with functions which do
    Stefan> nothing if the key is already bound?), but it's an issue that affects
    Stefan> only those people who hack on the code of the very Emacs they're
    Stefan> running, so it's not super-high priority.

At least for kmacro.el, any reason we canʼt put those
`global-set-key's in bindings.el?

Robert
-- 

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

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

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> 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)
>
> AFAICT the problem you describe is not specific to `loaddefs.el`.
> The same thing can happen with any file that has a `global-set-key` call
> at top-level.
>
> This reloading business is supposed to happen only if the in-memory
> doc-string-reference is out-of-sync with the installed files, presumably
> because you're running Emacs "in place" and the files have changed in
> the mean time.
> If that's indeed your situation, then "all is well": the problem you're
> seeing is "on purpose".  You can fix it by removing the above reloading
> mechanism (in exchange for being unable to see the docstring in those
> cases where the reloading would be needed).
>

Alas, the "supposed to happen only" is apparently not the case. The
Emacs where I see this is an Emacs installation. In the case of macOS,
this means "make install" has created an Emacs.app directory, a "bundle"
as it is called on macOS, containing what a "normal" installation would
contain. That Emacs.app I copied to the Desktop folder and start if from
there.

Too bad that I don't have a debug build so that I could see more.
Why does it think in my case that it needs to reread_doc_file?

> I tend to see this every once in a while where `C-x C-c` (which
> I normally rebind to a less-drastic operation) gets redefined
> to its default binding because `files.elc` gets reloaded.  🙂
>
> Maybe we should try and work harder to make such reloading more harmless
> (e.g. replace the `define-key/global-set-key`s with functions which do
> nothing if the key is already bound?), but it's an issue that affects
> only those people who hack on the code of the very Emacs they're
> running, so it's not super-high priority.

See above 🤷.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, murray.alex <at> gmail.com, luangruo <at> yahoo.com,
 monnier <at> iro.umontreal.ca, 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Mon, 02 Jun 2025 18:38:03 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>   murray.alex <at> gmail.com,
>   luangruo <at> yahoo.com,  Eli Zaretskii <eliz <at> gnu.org>,  78582 <at> debbugs.gnu.org
> Date: Mon, 02 Jun 2025 16:26:50 +0200
> 
> >>>>> On Mon, 02 Jun 2025 10:11:16 -0400, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> said:
> 
>     Stefan> Maybe we should try and work harder to make such reloading more harmless
>     Stefan> (e.g. replace the `define-key/global-set-key`s with functions which do
>     Stefan> nothing if the key is already bound?), but it's an issue that affects
>     Stefan> only those people who hack on the code of the very Emacs they're
>     Stefan> running, so it's not super-high priority.
> 
> At least for kmacro.el, any reason we canʼt put those
> `global-set-key's in bindings.el?

It would make the maintenance a tad harder, because the bindings will
be in a different file.  I'd say that benefits are not worth the
downsides in this case.

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

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

> Alas, the "supposed to happen only" is apparently not the case. The
> Emacs where I see this is an Emacs installation. In the case of macOS,
> this means "make install" has created an Emacs.app directory, a "bundle"
> as it is called on macOS, containing what a "normal" installation would
> contain. That Emacs.app I copied to the Desktop folder and start if from
> there.
>
> Too bad that I don't have a debug build so that I could see more.
> Why does it think in my case that it needs to reread_doc_file?

  if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc))))
    {
      Lisp_Object tem = get_doc_string (doc, 0);
      if (NILP (tem) && try_reload)
	{
	  /* The file is newer, we need to reset the pointers.  */
	  reread_doc_file (Fcar_safe (doc));
	  try_reload = false;
	  goto retry;
	}
      doc = tem;
    }

so it's because `get_doc_string` returned nil.
Usually this is because the doc reference points to a place that
"doesn't look right" (is not immediately preceded by `#@NNN`).

So maybe check the raw doc-string reference for `rectangle-mark-mode`:

    (nth 2 (symbol-function 'rectangle-mark-mode))

gives me ("loaddefs.elc" . 1044279).
Then go look at loaddefs.elc to see if that byte position points to
a docstring?
Or maybe the problem is somewhere in our handling of preloaded files
(i.e. those where the doc string reference uses a relative file name as
above) where it ends up looking in the wrong directory?


        Stefan

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

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

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Alas, the "supposed to happen only" is apparently not the case. The
>> Emacs where I see this is an Emacs installation. In the case of macOS,
>> this means "make install" has created an Emacs.app directory, a "bundle"
>> as it is called on macOS, containing what a "normal" installation would
>> contain. That Emacs.app I copied to the Desktop folder and start if from
>> there.
>>
>> Too bad that I don't have a debug build so that I could see more.
>> Why does it think in my case that it needs to reread_doc_file?
>
>   if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc))))
>     {
>       Lisp_Object tem = get_doc_string (doc, 0);
>       if (NILP (tem) && try_reload)
> 	{
> 	  /* The file is newer, we need to reset the pointers.  */
> 	  reread_doc_file (Fcar_safe (doc));
> 	  try_reload = false;
> 	  goto retry;
> 	}
>       doc = tem;
>     }
>
> so it's because `get_doc_string` returned nil.
> Usually this is because the doc reference points to a place that
> "doesn't look right" (is not immediately preceded by `#@NNN`).
>
> So maybe check the raw doc-string reference for `rectangle-mark-mode`:
>
>     (nth 2 (symbol-function 'rectangle-mark-mode))
>
> gives me ("loaddefs.elc" . 1044279).

That's a good idea. On my Emacs in question, after a fresh start

ELISP> (nth 2 (symbol-function 'rectangle-mark-mode))
("loaddefs.elc" . 1059364)

ELISP> (format "%x" 1059364)
"102a24"

> Then go look at loaddefs.elc to see if that byte position points to
> a docstring?

In hexl

2866 6e20 5354 4152 5420 454e 4420 5354  (fn START END ST
001029f0: 4152 542d 4154 2026 6f70 7469 6f6e 616c  ART-AT &optional
00102a00: 2046 4f52 4d41 5429 1f23 4037 3539 2054   FORMAT).#@759 T
00102a10: 6f67 676c 6520 7468 6520 7265 6769 6f6e  oggle the region
00102a20: 2061 7320 7265 6374 616e 6775 6c61 722e   as rectangular.
00102a30: 0a0a 4163 7469 7661 7465 7320 7468 6520  ..Activates the 
00102a40: 7265 6769 6f6e 2069 6620 6974 2773 2069  region if it's i

which is pretty far from the #@759. So the question is how gets the
wrong offset into the function-documentation, or maybe how gets
loaddefs.elc modified. Weird.

> Or maybe the problem is somewhere in our handling of preloaded files
> (i.e. those where the doc string reference uses a relative file name as
> above) where it ends up looking in the wrong directory?

Could be, but the directories in question at least look okay.

ELISP> lisp-directory
"/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/"

ELISP> doc-directory
"/Users/gerd/Desktop/Emacs.app/Contents/Resources/etc/"

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

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

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

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>>> Alas, the "supposed to happen only" is apparently not the case. The
>>> Emacs where I see this is an Emacs installation. In the case of macOS,
>>> this means "make install" has created an Emacs.app directory, a "bundle"
>>> as it is called on macOS, containing what a "normal" installation would
>>> contain. That Emacs.app I copied to the Desktop folder and start if from
>>> there.
>>>
>>> Too bad that I don't have a debug build so that I could see more.
>>> Why does it think in my case that it needs to reread_doc_file?
>>
>>   if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc))))
>>     {
>>       Lisp_Object tem = get_doc_string (doc, 0);
>>       if (NILP (tem) && try_reload)
>> 	{
>> 	  /* The file is newer, we need to reset the pointers.  */
>> 	  reread_doc_file (Fcar_safe (doc));
>> 	  try_reload = false;
>> 	  goto retry;
>> 	}
>>       doc = tem;
>>     }
>>
>> so it's because `get_doc_string` returned nil.
>> Usually this is because the doc reference points to a place that
>> "doesn't look right" (is not immediately preceded by `#@NNN`).
>>
>> So maybe check the raw doc-string reference for `rectangle-mark-mode`:
>>
>>     (nth 2 (symbol-function 'rectangle-mark-mode))
>>
>> gives me ("loaddefs.elc" . 1044279).
>
> That's a good idea. On my Emacs in question, after a fresh start
>
> ELISP> (nth 2 (symbol-function 'rectangle-mark-mode))
> ("loaddefs.elc" . 1059364)
>
> ELISP> (format "%x" 1059364)
> "102a24"
>
>> Then go look at loaddefs.elc to see if that byte position points to
>> a docstring?
>
> In hexl
>
> 2866 6e20 5354 4152 5420 454e 4420 5354  (fn START END ST
> 001029f0: 4152 542d 4154 2026 6f70 7469 6f6e 616c  ART-AT &optional
> 00102a00: 2046 4f52 4d41 5429 1f23 4037 3539 2054   FORMAT).#@759 T
> 00102a10: 6f67 676c 6520 7468 6520 7265 6769 6f6e  oggle the region
> 00102a20: 2061 7320 7265 6374 616e 6775 6c61 722e   as rectangular.
> 00102a30: 0a0a 4163 7469 7661 7465 7320 7468 6520  ..Activates the 
> 00102a40: 7265 6769 6f6e 2069 6620 6974 2773 2069  region if it's i
>
> which is pretty far from the #@759. So the question is how gets the
> wrong offset into the function-documentation, or maybe how gets
> loaddefs.elc modified. Weird.
>
>> Or maybe the problem is somewhere in our handling of preloaded files
>> (i.e. those where the doc string reference uses a relative file name as
>> above) where it ends up looking in the wrong directory?
>
> Could be, but the directories in question at least look okay.
>
> ELISP> lisp-directory
> "/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/"
>
> ELISP> doc-directory
> "/Users/gerd/Desktop/Emacs.app/Contents/Resources/etc/"

And in another Emacs.app installation I did just now, the offset looks
right.

ELISP> (function-documentation 'rectangle-mark-mode)
("loaddefs.elc" . 1059343)

ELISP> (format "%x" 1059343)
"102a0f"

001029f0: 4152 542d 4154 2026 6f70 7469 6f6e 616c  ART-AT &optional
00102a00: 2046 4f52 4d41 5429 1f23 4037 3539 2054   FORMAT).#@759 T
00102a10: 6f67 676c 6520 7468 6520 7265 6769 6f6e  oggle the region

And the problem doesn't occur then, of course.

Nice.

And hard to find. I guess I'll go and move the bindings to bindings.el
in my Emacs instead of wasting my time :-).

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

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

> which is pretty far from the #@759. So the question is how gets the
> wrong offset into the function-documentation, or maybe how gets
> loaddefs.elc modified. Weird.

Looks like something happened in the build which caused the
`loaddefs.el` to be updated "too late", i.e. after the last dump.
I think I've seen this happen but I have no idea what circumstances can
trigger it.


        Stefan

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

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

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> which is pretty far from the #@759. So the question is how gets the
>> wrong offset into the function-documentation, or maybe how gets
>> loaddefs.elc modified. Weird.
>
> Looks like something happened in the build which caused the
> `loaddefs.el` to be updated "too late", i.e. after the last dump.
> I think I've seen this happen but I have no idea what circumstances can
> trigger it.
>
Yeah, I guess that's the most likely possibility.

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

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

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  murray.alex <at> gmail.com,
>   luangruo <at> yahoo.com,  78582 <at> debbugs.gnu.org
> Date: Mon, 02 Jun 2025 21:23:00 +0200
> 
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> >> which is pretty far from the #@759. So the question is how gets the
> >> wrong offset into the function-documentation, or maybe how gets
> >> loaddefs.elc modified. Weird.
> >
> > Looks like something happened in the build which caused the
> > `loaddefs.el` to be updated "too late", i.e. after the last dump.
> > I think I've seen this happen but I have no idea what circumstances can
> > trigger it.
> >
> Yeah, I guess that's the most likely possibility.

If that's the case, then saying "make" in the build tree should
re-dump Emacs.  Does it?

(It also means we probably have a subtle bug in our Makefile rules,
because this situation should not happen.)

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

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: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Tue, 03 Jun 2025 14:05:24 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  murray.alex <at> gmail.com,
>>   luangruo <at> yahoo.com,  78582 <at> debbugs.gnu.org
>> Date: Mon, 02 Jun 2025 21:23:00 +0200
>> 
>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> 
>> >> which is pretty far from the #@759. So the question is how gets the
>> >> wrong offset into the function-documentation, or maybe how gets
>> >> loaddefs.elc modified. Weird.
>> >
>> > Looks like something happened in the build which caused the
>> > `loaddefs.el` to be updated "too late", i.e. after the last dump.
>> > I think I've seen this happen but I have no idea what circumstances can
>> > trigger it.
>> >
>> Yeah, I guess that's the most likely possibility.
>
> If that's the case, then saying "make" in the build tree should
> re-dump Emacs.  Does it?
>
> (It also means we probably have a subtle bug in our Makefile rules,
> because this situation should not happen.)

No longer reproducible, alas. I built that Emacs.app, copied it to the
desktop, and proceeded with the repo independently of it, which included
new builds.

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

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: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Wed, 04 Jun 2025 12:39:17 +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: Eli Zaretskii <eliz <at> gnu.org>,  murray.alex <at> gmail.com,
>>>   luangruo <at> yahoo.com,  78582 <at> debbugs.gnu.org
>>> Date: Mon, 02 Jun 2025 21:23:00 +0200
>>> 
>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> 
>>> >> which is pretty far from the #@759. So the question is how gets the
>>> >> wrong offset into the function-documentation, or maybe how gets
>>> >> loaddefs.elc modified. Weird.
>>> >
>>> > Looks like something happened in the build which caused the
>>> > `loaddefs.el` to be updated "too late", i.e. after the last dump.
>>> > I think I've seen this happen but I have no idea what circumstances can
>>> > trigger it.
>>> >
>>> Yeah, I guess that's the most likely possibility.
>>
>> If that's the case, then saying "make" in the build tree should
>> re-dump Emacs.  Does it?
>>
>> (It also means we probably have a subtle bug in our Makefile rules,
>> because this situation should not happen.)
>
> No longer reproducible, alas. I built that Emacs.app, copied it to the
> desktop, and proceeded with the repo independently of it, which included
> new builds.

I tried if I could see something in the Makefiles, but to no avail.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: murray.alex <at> gmail.com, luangruo <at> yahoo.com, monnier <at> iro.umontreal.ca,
 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Thu, 05 Jun 2025 17:19:10 +0300

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: monnier <at> iro.umontreal.ca,  murray.alex <at> gmail.com,  luangruo <at> yahoo.com,
>   78582 <at> debbugs.gnu.org
> Date: Wed, 04 Jun 2025 12:39:17 +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: Eli Zaretskii <eliz <at> gnu.org>,  murray.alex <at> gmail.com,
> >>>   luangruo <at> yahoo.com,  78582 <at> debbugs.gnu.org
> >>> Date: Mon, 02 Jun 2025 21:23:00 +0200
> >>> 
> >>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> >>> 
> >>> >> which is pretty far from the #@759. So the question is how gets the
> >>> >> wrong offset into the function-documentation, or maybe how gets
> >>> >> loaddefs.elc modified. Weird.
> >>> >
> >>> > Looks like something happened in the build which caused the
> >>> > `loaddefs.el` to be updated "too late", i.e. after the last dump.
> >>> > I think I've seen this happen but I have no idea what circumstances can
> >>> > trigger it.
> >>> >
> >>> Yeah, I guess that's the most likely possibility.
> >>
> >> If that's the case, then saying "make" in the build tree should
> >> re-dump Emacs.  Does it?
> >>
> >> (It also means we probably have a subtle bug in our Makefile rules,
> >> because this situation should not happen.)
> >
> > No longer reproducible, alas. I built that Emacs.app, copied it to the
> > desktop, and proceeded with the repo independently of it, which included
> > new builds.
> 
> I tried if I could see something in the Makefiles, but to no avail.

I guess we need to wait for this to surface again.

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

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: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Thu, 05 Jun 2025 16:26:16 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: monnier <at> iro.umontreal.ca,  murray.alex <at> gmail.com,  luangruo <at> yahoo.com,
>>   78582 <at> debbugs.gnu.org
>> Date: Wed, 04 Jun 2025 12:39:17 +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: Eli Zaretskii <eliz <at> gnu.org>,  murray.alex <at> gmail.com,
>> >>>   luangruo <at> yahoo.com,  78582 <at> debbugs.gnu.org
>> >>> Date: Mon, 02 Jun 2025 21:23:00 +0200
>> >>> 
>> >>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> >>> 
>> >>> >> which is pretty far from the #@759. So the question is how gets the
>> >>> >> wrong offset into the function-documentation, or maybe how gets
>> >>> >> loaddefs.elc modified. Weird.
>> >>> >
>> >>> > Looks like something happened in the build which caused the
>> >>> > `loaddefs.el` to be updated "too late", i.e. after the last dump.
>> >>> > I think I've seen this happen but I have no idea what circumstances can
>> >>> > trigger it.
>> >>> >
>> >>> Yeah, I guess that's the most likely possibility.
>> >>
>> >> If that's the case, then saying "make" in the build tree should
>> >> re-dump Emacs.  Does it?
>> >>
>> >> (It also means we probably have a subtle bug in our Makefile rules,
>> >> because this situation should not happen.)
>> >
>> > No longer reproducible, alas. I built that Emacs.app, copied it to the
>> > desktop, and proceeded with the repo independently of it, which included
>> > new builds.
>> 
>> I tried if I could see something in the Makefiles, but to no avail.
>
> I guess we need to wait for this to surface again.

Maybe the OP has some info, log files or something from the build he is
using?

Previous Next

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