GNU bug report logs -
#78582
30.1; which-key-mode overwrites custom key bindings
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
I confirmed your suggested steps DO produce the problem.
Specifically: From a terminal enter: emacs -Q
In the *scratch* buffer that presents paste
(global-set-key [f3] 'nonincremental-repeat-search-forward)
(custom-set-variables '(which-key-mode t))
C-x C-e the lines in presented order.
C-h k f3 quickly and see nonincremental-repeat-search-forward
C-h and wait for the menu before typing k f3
kmacro-start-macro-or-insert-counter is now in the *Help* buffer.
||
On 5/26/25 05:50, Eli Zaretskii wrote:
>> 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.
[Message part 2 (text/html, inline)]
This bug report was last modified 9 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.