GNU bug report logs -
#78582
30.1; which-key-mode overwrites custom key bindings
Previous Next
Full log
View this message in rfc822 format
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> 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.
This bug report was last modified 71 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.