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

Previous Next

Full log

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.

Previous Next

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