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

Previous Next

Full log

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/"

Previous Next

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