I was briefly unable to recreate the problem myself today. It's
complicated
because I've never had a UNIX type machine so I'm distracted by
the learning
curve and making platform mistakes. The problem does exist
though.
These are, hopefully, the reasons it didn't work for you.
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.
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 .
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.
> Date: Sat, 24 May 2025 16:16:23 -0500
> From: Rick <rbielaws@gmail.com>
>
> The problem can't be reproduced with -Q however with -q one only needs
> 2 lines in .emacs to recreate. Also, be forewarned that the problem
> DOES NOT happen if you specify --debug-init. This is the only command
> line option I tried and it hampered predictable recreation efforts.
>
> .emacs content =
>
> (global-set-key [f3] 'describe-key)
> (custom-set-variables '(which-key-mode t))
>
> Upon startup, quickly type C-h k F3.
> It shows F3 is bound to describe-key as expected and the key works
> normally as do any others you have set. Try it as much as you like.
>
> Now comes the insidious part. If you type the 'k' a little bit too
> slowly F3 is overwritten by kmacro-start-macro-or-insert-counter.
> Specifically, type C-h and wait before typing k. Then F3.
I cannot reproduce this. I tried both on GNU/Linux and on MS-Windows,
with Emacs 30.1 and the current master branch (which will be some day
Emacs 31), and I don't see the problem. But then I don't actually
understand what you mean by "F3 is overwritten by
kmacro-start-macro-or-insert-counter" -- can you describe what you
see? What I see is the *Help* buffer showing the description of
describe-key, as expected. And that doesn't change if I type 'k'
immediately or after a delay, the only difference between these two is
that when I wait before typing 'k', Emacs pops up the which-key
display showing the possible keys to type after "C-h". But once I
type 'k', all the rest is the same regardless.
Are you sure you don't have some early-init or site-start file which
could explain the problem?
Does the problem happen if you start "emacs -Q" and then evaluate
those two lines in *scratch* ?
Can anyone else reproduce this strange problem?