GNU bug report logs -
#78582
30.1; which-key-mode overwrites custom key bindings
Previous Next
Full log
Message #65 received at 78582 <at> debbugs.gnu.org (full text, mbox):
> 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 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.