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 >> Cc:78582@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.