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

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 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: 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 :-).

Previous Next

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