GNU logs - #78582, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Resent-From: Rick <rbielaws@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 24 May 2025 21:17:02 +0000
Resent-Message-ID: <handler.78582.B.174812140530527 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 78582 <at> debbugs.gnu.org
Content-Type: multipart/alternative;
 boundary="------------04OD0O1wVrqV9rgTd1tkxCeX"
Message-ID: <d2414b0f-dde0-4c93-bffd-06fc241327a9@HIDDEN>
Date: Sat, 24 May 2025 16:16:23 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
From: Rick <rbielaws@HIDDEN>
Received-SPF: pass client-ip=2607:f8b0:4864:20::d2b;
 envelope-from=rbielaws@HIDDEN; helo=mail-io1-xd2b.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

This is a multi-part message in MIME format.
--------------04OD0O1wVrqV9rgTd1tkxCeX
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

|--text follows this line-- ||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. Other situations and chords have a similar 
effect but the common thread is that no key combination in particular 
ever causes the problem reliably. It seems to only happen if you use a 
prefix (C-u) or take too long typing the 2nd key in a combination but I 
don't really know. Possibly useful observations: I noticed 2 other 
clobbered keys while troubleshooting F3 but assumed they were related 
and didn't look at them further. I did, however notice they require 
different circumstances from those above to be reset because both 
mouse-1 and M-i were ||reset to defaults independently of F3. That is, I observed an instance 
where M-i was reset but F3 was not. I also saw F3 reset when mouse-2 was 
not.|
|Another useful point is that once a key has been reverted to defaults, 
if you re-assert your preference it will never revert again. I suspect 
--debug-init invokes whatever initially causes the keys to be 
overwritten and site-start is then in the position otherwise occupied by 
someone re-asserting their preferences. If true, it explains how keys 
can 'stick' after a ||--debug-init start. If other things have a similar effect, something 
many users do may limit the number of people experiencing the problem. |||||Or, maybe it's something specific to this build since I've never had a
Ubuntu machine before, my config has never seen a non-Windows build till
now.

|In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, 
cairo version 1.18.0) of 2025-05-11 built on lcy02-amd64-059 Repository 
revision: 9328fd1ab06a1a1f85077fd1caadf9128c90f6c1 Repository branch: 
master System Description: Ubuntu 24.04.2 LTS Configured using: 
'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3 
--without-xaw3d --with-modules --with-cairo 
--with-native-compilation=aot --with-pgtk --with-xinput2 
--with-tree-sitter 'CFLAGS=-isystem 
/build/emacs/parts/emacs/install/usr/include -isystem 
/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem 
/build/emacs/stage/usr/include -O2' 'CPPFLAGS=-isystem 
/build/emacs/parts/emacs/install/usr/include -isystem 
/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem 
/build/emacs/stage/usr/include' 
'LDFLAGS=-L/build/emacs/parts/emacs/install/lib 
-L/build/emacs/parts/emacs/install/usr/lib 
-L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu 
-L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu 
-L/build/emacs/stage/usr/lib'' Configured features: ACL CAIRO DBUS 
FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF 
LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER 
PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS 
TREE_SITTER WEBP XIM GTK3 ZLIB Important settings: value of $LANG: 
en_US.UTF-8 value of $XMODIFIERS: @im=ibus locale-coding-system: 
utf-8-unix Major mode: Fundamental Minor modes in effect: tooltip-mode: 
t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t 
mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t 
file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t 
minibuffer-regexp-mode: t buffer-read-only: t line-number-mode: t 
indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t 
auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None 
found. Features: (shadow sort mail-extr emacsbug message mailcap 
yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache 
epa derived epg rfc6068 epg-config gnus-util time-date mm-decode 
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader 
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils 
shortdoc text-property-search kmacro byte-opt help-fns radix-tree 
site-start comp cl-seq comp-cstr cl-extra help-mode comp-common warnings 
icons subr-x rx gv cl-loaddefs cl-lib bytecomp byte-compile rmc 
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook 
vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win 
term/common-win touch-screen pgtk-dnd tool-bar dnd fontset image 
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode 
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu 
timer select scroll-bar mouse jit-lock font-lock syntax font-core 
term/tty-colors frame minibuffer nadvice seq simple cl-generic 
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese 
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek 
romanian slovak czech european ethiopic indian cyrillic chinese 
composite emoji-zwj charscript charprop case-table epa-hook 
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs 
theme-loaddefs faces cus-face macroexp files window text-properties 
overlay sha1 md5 base64 format env code-pages mule custom widget keymap 
hashtable-print-readable backquote threads dbusbind inotify 
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk 
lcms2 multi-tty move-toolbar make-network-process native-compile emacs) 
Memory information: ((conses 16 123573 16384) (symbols 48 7625 0) 
(strings 32 25412 1713) (string-bytes 1 1761900) (vectors 16 14083) 
(vector-slots 8 177707 11252) (floats 8 85 3) (intervals 56 476 0) 
(buffers 992 12)) |

--------------04OD0O1wVrqV9rgTd1tkxCeX
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <pre><code>--text follows this line--

</code><code>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))

</code><code>Upon startup, quickly type C-h k F3.
It shows F3 is bound to describe-key</code> as expected and the key works 
normally as do any others you have set. Try it as much as you like.

Now comes the <code></code>insidious part.  If you type the 'k' a little bit too
slowly F3 is overwritten by <code>kmacro-start-macro-or-insert-counter.
Specifically, type C-h and wait before typing k.  Then F3.
Other situations and chords have a similar effect but the common
thread is that no key combination in particular ever causes the problem
reliably.  It seems to only happen if you use a prefix (C-u) or take too 
long typing the 2nd key in a combination but I don't really know.

Possibly useful observations:

I noticed 2 other clobbered keys while troubleshooting F3 but assumed 
they were related and didn't look at them further.  I did, however
notice they require different circumstances from those above to be reset
because both mouse-1 and M-i were </code><code>reset to defaults independently of F3.
That is, I observed an instance where M-i was reset but F3 was not.  I 
also saw F3 reset when mouse-2 was not.</code>
<code>
Another useful point is that once a key has been reverted to defaults,
if you re-assert your preference it will never revert again.  I suspect
--debug-init invokes whatever initially causes the keys to be overwritten
and site-start is then in the position otherwise occupied by someone 
re-asserting their preferences.  If true, it explains how keys can 'stick' 
after a </code><code>--debug-init start.  If other things have a similar effect, 
something many users do may limit the number of people experiencing the
problem.
</code><code>
</code><code></code>Or, maybe it's something specific to this build since I've never had a
Ubuntu machine before, my config has never seen a non-Windows build till
now.

<code>
In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,
 cairo version 1.18.0) of 2025-05-11 built on lcy02-amd64-059
Repository revision: 9328fd1ab06a1a1f85077fd1caadf9128c90f6c1
Repository branch: master
System Description: Ubuntu 24.04.2 LTS

Configured using:
 'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3
 --without-xaw3d --with-modules --with-cairo
 --with-native-compilation=aot --with-pgtk --with-xinput2
 --with-tree-sitter 'CFLAGS=-isystem
 /build/emacs/parts/emacs/install/usr/include -isystem
 /build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem
 /build/emacs/stage/usr/include -O2' 'CPPFLAGS=-isystem
 /build/emacs/parts/emacs/install/usr/include -isystem
 /build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -isystem
 /build/emacs/stage/usr/include'
 'LDFLAGS=-L/build/emacs/parts/emacs/install/lib
 -L/build/emacs/parts/emacs/install/usr/lib
 -L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu
 -L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu
 -L/build/emacs/stage/usr/lib''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils shortdoc text-property-search
kmacro byte-opt help-fns radix-tree site-start comp cl-seq comp-cstr
cl-extra help-mode comp-common warnings icons subr-x rx gv cl-loaddefs
cl-lib bytecomp byte-compile rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/pgtk-win pgtk-win term/common-win touch-screen pgtk-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo gtk pgtk
lcms2 multi-tty move-toolbar make-network-process native-compile emacs)

Memory information:
((conses 16 123573 16384) (symbols 48 7625 0) (strings 32 25412 1713)
 (string-bytes 1 1761900) (vectors 16 14083)
 (vector-slots 8 177707 11252) (floats 8 85 3) (intervals 56 476 0)
 (buffers 992 12))

</code></pre>
    <p></p>
  </body>
</html>

--------------04OD0O1wVrqV9rgTd1tkxCeX--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Rick <rbielaws@HIDDEN>
Subject: bug#78582: Acknowledgement (30.1; which-key-mode overwrites
 custom key bindings)
Message-ID: <handler.78582.B.174812140530527.ack <at> debbugs.gnu.org>
References: <d2414b0f-dde0-4c93-bffd-06fc241327a9@HIDDEN>
X-Gnu-PR-Message: ack 78582
X-Gnu-PR-Package: emacs
Reply-To: 78582 <at> debbugs.gnu.org
Date: Sat, 24 May 2025 21:17:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 78582 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
78582: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78582
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 25 May 2025 06:17:02 +0000
Resent-Message-ID: <handler.78582.B78582.174815380721104 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Rick <rbielaws@HIDDEN>
Cc: 78582 <at> debbugs.gnu.org
Date: Sun, 25 May 2025 09:16:25 +0300
Message-Id: <86sektz03q.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <d2414b0f-dde0-4c93-bffd-06fc241327a9@HIDDEN> (message from
 Rick on Sat, 24 May 2025 16:16:23 -0500)
References: <d2414b0f-dde0-4c93-bffd-06fc241327a9@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> Date: Sat, 24 May 2025 16:16:23 -0500
> From: Rick <rbielaws@HIDDEN>
> 
> 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?

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Resent-From: Rick <rbielaws@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 25 May 2025 23:20:01 +0000
Resent-Message-ID: <handler.78582.B78582.174821517425313 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 78582 <at> debbugs.gnu.org
Content-Type: multipart/alternative;
 boundary="------------Yn8nYNZWR35Us9jgJNEDsk5n"
Message-ID: <592d5998-c453-444b-9c02-b71f331b6f9b@HIDDEN>
Date: Sun, 25 May 2025 18:19:20 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Rick <rbielaws@HIDDEN>
References: <d2414b0f-dde0-4c93-bffd-06fc241327a9@HIDDEN>
 <86sektz03q.fsf@HIDDEN>
Content-Language: en-US
In-Reply-To: <86sektz03q.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

This is a multi-part message in MIME format.
--------------Yn8nYNZWR35Us9jgJNEDsk5n
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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.


On Sun, May 25, 2025, 1:16 AM Eli Zaretskii <eliz@HIDDEN> wrote:

     > Date: Sat, 24 May 2025 16:16:23 -0500
     > From: Rick <rbielaws@HIDDEN>
     >
     > 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?

--------------Yn8nYNZWR35Us9jgJNEDsk5n
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I was briefly unable to recreate the problem myself today.  It's
      complicated <br>
      because I've never had a UNIX type machine so I'm distracted by
      the learning <br>
      curve and making platform mistakes.  The problem does exist
      though.<br>
    </p>
    <p>These are, hopefully, the reasons it didn't work for you.<br>
    </p>
    <p>1) I didn't realize I never used -q.  I edited the wrong .desktop
      file.  Using -q<br>
          prevents the two statements that set up the problem from
      executing.  You CAN<br>
          specify --no-site-file but -q or -Q destroy the setup
      conditions and --debug-init <br>
          often prevents the problem from occurring too so don't do that
      either.<br>
    </p>
    <p>2) I used 'nonincremental-search-forward rather than
      'describe-key as the example <br>
          function assigned to F3 when I developed the example.  I have
      no idea why using<br>
          'describe-key makes a difference.  In fact, if I use it, the
      menu of possible prefix<br>
          completions never shows up.  Just the mini-buffer prompt with
      ? if I want help.<br>
          Hard to say if this isn't a completely different problem or
      perhaps related.<br>
      In any case it seems saver to use 'nonincremental-search-forward .</p>
    <p>As I think about the strangeness of the symptoms I can't help but
      think it's <br>
      related to how the build loads into memory and something is
      assuming some<br>
      block containing definitions has never loaded when, it not only
      has been, but <br>
      it has even been modified.  So the load is really a reload that's
      revering things. <br>
      Afterward, it knows it's been loaded and never overwrites that
      data again.<br>
      It's the only thing I can think of that explains why I've never
      caught it <br>
      overwriting the same keys multiple times.<br>
    </p>
    <div class="gmail_quote gmail_quote_container">
      <div dir="ltr" class="gmail_attr"><br>
      </div>
      <div dir="ltr" class="gmail_attr">On Sun, May 25, 2025, 1:16 AM
        Eli Zaretskii &lt;<a href="mailto:eliz@HIDDEN"
          class="moz-txt-link-freetext">eliz@HIDDEN</a>&gt; wrote:<br>
      </div>
      <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt;
        Date: Sat, 24 May 2025 16:16:23 -0500<br>
        &gt; From: Rick &lt;<a href="mailto:rbielaws@HIDDEN"
          target="_blank" rel="noreferrer" class="moz-txt-link-freetext">rbielaws@HIDDEN</a>&gt;<br>
        &gt; <br>
        &gt; The problem can't be reproduced with -Q however with -q one
        only needs<br>
        &gt; 2 lines in .emacs to recreate.  Also, be forewarned that
        the problem <br>
        &gt; DOES NOT happen if you specify --debug-init.  This is the
        only command <br>
        &gt; line option I tried and it hampered predictable recreation
        efforts.<br>
        &gt; <br>
        &gt; .emacs content =<br>
        &gt; <br>
        &gt;     (global-set-key [f3] 'describe-key) <br>
        &gt;     (custom-set-variables '(which-key-mode t))<br>
        &gt; <br>
        &gt; Upon startup, quickly type C-h k F3.<br>
        &gt; It shows F3 is bound to describe-key as expected and the
        key works <br>
        &gt; normally as do any others you have set. Try it as much as
        you like.<br>
        &gt; <br>
        &gt; Now comes the insidious part.  If you type the 'k' a little
        bit too<br>
        &gt; slowly F3 is overwritten by
        kmacro-start-macro-or-insert-counter.<br>
        &gt; Specifically, type C-h and wait before typing k.  Then F3.<br>
        <br>
        I cannot reproduce this.  I tried both on GNU/Linux and on
        MS-Windows,<br>
        with Emacs 30.1 and the current master branch (which will be
        some day<br>
        Emacs 31), and I don't see the problem.  But then I don't
        actually<br>
        understand what you mean by "F3 is overwritten by<br>
        kmacro-start-macro-or-insert-counter" -- can you describe what
        you<br>
        see?  What I see is the *Help* buffer showing the description of<br>
        describe-key, as expected.  And that doesn't change if I type
        'k'<br>
        immediately or after a delay, the only difference between these
        two is<br>
        that when I wait before typing 'k', Emacs pops up the which-key<br>
        display showing the possible keys to type after "C-h".  But once
        I<br>
        type 'k', all the rest is the same regardless.<br>
        <br>
        Are you sure you don't have some early-init or site-start file
        which<br>
        could explain the problem?<br>
        <br>
        Does the problem happen if you start "emacs -Q" and then
        evaluate<br>
        those two lines in *scratch* ?<br>
        <br>
        Can anyone else reproduce this strange problem?<br>
      </blockquote>
    </div>
  </body>
</html>

--------------Yn8nYNZWR35Us9jgJNEDsk5n--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 26 May 2025 10:51:01 +0000
Resent-Message-ID: <handler.78582.B78582.174825662025320 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78582
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Rick <rbielaws@HIDDEN>
Cc: 78582 <at> debbugs.gnu.org
Received: via spool by 78582-submit <at> debbugs.gnu.org id=B78582.174825662025320
          (code B ref 78582); Mon, 26 May 2025 10:51:01 +0000
Received: (at 78582) by debbugs.gnu.org; 26 May 2025 10:50:20 +0000
Received: from localhost ([127.0.0.1]:54956 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uJVPP-0006Ze-8m
	for submit <at> debbugs.gnu.org; Mon, 26 May 2025 06:50:19 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:35956)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uJVPK-0006WA-5Y
 for 78582 <at> debbugs.gnu.org; Mon, 26 May 2025 06:50:16 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1uJVPE-00068v-Gz; Mon, 26 May 2025 06:50:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=WkD9MsbMzn/UZ0vdRSCG+JJZv3Z+IIEdz6Vz4iV6vdQ=; b=HX6OlaCIh/f4
 cJtaSh74Vv4MP1YiP+U3jvjtBVviVr9rqwKgf2bSJwSqtwNpCNudsZvIzaWRNPIox5qgXw/HDuJjt
 sHAkMZsnkivi3yxiRHe7QFGxNC6MSAkd7ZHwIunafvCkHYoF7tjywmntp2+VdbDJLIXO8jCf3Fm+C
 zahrBKZ0Cm7tgFF736KQGUL0CZtTmceq89kp/0ARLLyCIdkIFUiNzLCcv5sMF2U+zdHX12zQih73o
 vEYWusg/0v4MGXeET0XYoUMtw+Y+lFUJRC3Z2Jr0xSoxzfvzbdJSjU1iqNYFU22bLRBXoJC/NGU3N
 8DrSn8u1rv01gCrV47Puyw==;
Date: Mon, 26 May 2025 13:50:05 +0300
Message-Id: <86frgrzlwi.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <592d5998-c453-444b-9c02-b71f331b6f9b@HIDDEN> (message from
 Rick on Sun, 25 May 2025 18:19:20 -0500)
References: <d2414b0f-dde0-4c93-bffd-06fc241327a9@HIDDEN>
 <86sektz03q.fsf@HIDDEN> <592d5998-c453-444b-9c02-b71f331b6f9b@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Sun, 25 May 2025 18:19:20 -0500
> From: Rick <rbielaws@HIDDEN>
> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Resent-From: Rick <rbielaws@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 26 May 2025 15:38:02 +0000
Resent-Message-ID: <handler.78582.B78582.174827382324386 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78582
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 78582 <at> debbugs.gnu.org
Received: via spool by 78582-submit <at> debbugs.gnu.org id=B78582.174827382324386
          (code B ref 78582); Mon, 26 May 2025 15:38:02 +0000
Received: (at 78582) by debbugs.gnu.org; 26 May 2025 15:37:03 +0000
Received: from localhost ([127.0.0.1]:58270 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uJZss-0006LC-3T
	for submit <at> debbugs.gnu.org; Mon, 26 May 2025 11:37:02 -0400
Received: from mail-il1-x12c.google.com ([2607:f8b0:4864:20::12c]:42348)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <rbielaws@HIDDEN>)
 id 1uJZsp-0006KX-Ez
 for 78582 <at> debbugs.gnu.org; Mon, 26 May 2025 11:37:00 -0400
Received: by mail-il1-x12c.google.com with SMTP id
 e9e14a558f8ab-3dc6f3fe907so6818445ab.1
 for <78582 <at> debbugs.gnu.org>; Mon, 26 May 2025 08:36:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1748273813; x=1748878613; darn=debbugs.gnu.org;
 h=in-reply-to:from:content-language:references:cc:to:subject
 :user-agent:mime-version:date:message-id:from:to:cc:subject:date
 :message-id:reply-to;
 bh=xqwnfII2p1acbWNX1hZKJ3kq8CECehx3NR+yk4KdrSk=;
 b=f3V/pfe3BHh6RgEnVjkK4b7dH/vp9qJ2QPLrKaUp3CQGpMP6pRW1lawCnwYj3eixPw
 tzBqXyd7O9sOvNPlqqK4d0MXRs4GjpVi2x6Mopww6W99bdzBDsrdCou4+CTJvKZOGVhR
 BFSGUh+nwOI6ypK2BoOTaYiVbIMjJhYmnT6xN2QY3mNXI4fnv8ekCxQd2BqWt7+yaECp
 2YJEcf0lA53+XSZx5PQiI33wn1GZi4lKWmVOxhS3J3E2ovDHX5xif0kM+gjFu1zZwf4w
 q0bNH5Q16kLFD/v0J+U6RURGrSIY5mFMklyjGt6hp/L9wmCmeDtMCAk7vxkFfprDk2gE
 9WlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1748273813; x=1748878613;
 h=in-reply-to:from:content-language:references:cc:to:subject
 :user-agent:mime-version:date:message-id:x-gm-message-state:from:to
 :cc:subject:date:message-id:reply-to;
 bh=xqwnfII2p1acbWNX1hZKJ3kq8CECehx3NR+yk4KdrSk=;
 b=f+I3aWNikTIviGuxFsO7CAZG+Q6rGz1RarjMfbissoQyT0T0Ym7fF22vMna/wyuBzD
 DN68dLS2iHQmSzBP8LW/ikNdktNUZkQZyqu06JqLb2ypJEWTQNNQlAMqFsfexFOn+fo1
 11flsKUwDhTADVhEwHrYCesCWhlkG4cgxh+ukNduXcfJq+yiRzDyJXgoV24suU//p65U
 8ZzpVwvuirT4CY7Hcmgw8IhGuqfwjNVyUjFoxA1jClzAHf3i+VUaFVY31RtGXjmRIeBM
 b+++UkhMpgEegAHLxQT5MUTPWaWeTt99fZXf5GKT+659rT8arN2tL9NV7SNrIrgMGOv6
 WAyA==
X-Gm-Message-State: AOJu0YxdKVgAvTpSNgNokdOHbsymBzTIW1ZL7UJxCaWt6iV2MXW7ystm
 Ty0a5l7JFQVBgjQQGcWiNUwRqb8Omxrc388QCW0ZaD1lQoGmrgju3LanAGUE5A==
X-Gm-Gg: ASbGncuDUxEygpQOz30v3EgJeZocglQYL+HdTvkwrO2PlfCQwcWLuUw46p0h3YrCalp
 YMlBBLR+D/C0ecHkH33Gs0lp70J24d0uh8/Xafc+kbR6sb3ufsCSmuFD1zGoNJYKp3ZTsZ33/Mw
 K1lAhFvdUePL8+MXwgL48emGSFV89Bx/N7mhwSEdeTFEaQCr2q+94eB5yfW1qx1HDOkmnOb7DCd
 qyGGWn4B9TG5DnolALKfUxzcObMgog2AU8FOtuSryvovl8DjwbCnJdPKQIBXgR3y289g03AuxAc
 zygMoFydzFwn33clJgTyuXNGmREfWQSmEkOfShXxDInY7PfGW0aJd699QkMQ4rO89W57Umiqhm7
 95cuUDLUC/OwQuJWFwcUqug==
X-Google-Smtp-Source: AGHT+IFBvGPmlkDG6KUew28g4pU7Bdw79JNeW9g1xU1glC5wUcpGlL0EzzTO9Gyy9fbd7kkd1SqILA==
X-Received: by 2002:a05:6e02:528:b0:3db:80f8:e8d4 with SMTP id
 e9e14a558f8ab-3dc92c1291bmr92149335ab.6.1748273813345; 
 Mon, 26 May 2025 08:36:53 -0700 (PDT)
Received: from ?IPV6:2601:447:c580:e8e0:2902:dcb5:a85c:cae2?
 ([2601:447:c580:e8e0:2902:dcb5:a85c:cae2])
 by smtp.gmail.com with ESMTPSA id
 8926c6da1cb9f-4fda7d9756bsm50877173.137.2025.05.26.08.36.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 08:36:53 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary="------------SsUHN29cQE9WeImXgFkUFXhT"
Message-ID: <7f0afc3e-1e34-4c56-880d-ffad33259f5d@HIDDEN>
Date: Mon, 26 May 2025 10:36:52 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <d2414b0f-dde0-4c93-bffd-06fc241327a9@HIDDEN>
 <86sektz03q.fsf@HIDDEN> <592d5998-c453-444b-9c02-b71f331b6f9b@HIDDEN>
 <86frgrzlwi.fsf@HIDDEN>
Content-Language: en-US
From: Rick <rbielaws@HIDDEN>
In-Reply-To: <86frgrzlwi.fsf@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

This is a multi-part message in MIME format.
--------------SsUHN29cQE9WeImXgFkUFXhT
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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@HIDDEN>
>> 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.
--------------SsUHN29cQE9WeImXgFkUFXhT
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I confirmed your suggested steps DO produce the problem.</p>
    <p>Specifically:  From a terminal enter:  emacs -Q</p>
    <p>In the *scratch* buffer that presents paste</p>
    <p><tt><font size="4">(global-set-key [f3]
          'nonincremental-repeat-search-forward)<br>
          (custom-set-variables '(which-key-mode t))</font><br>
      </tt><br>
      C-x C-e the lines in presented order.<br>
      C-h k f3 quickly and see nonincremental-repeat-search-forward<br>
      C-h and wait for the menu before typing k f3  <br>
      kmacro-start-macro-or-insert-counter is now in the *Help* buffer.</p>
    <pre><code>
</code></pre>
    <p></p>
    <div class="moz-cite-prefix">On 5/26/25 05:50, Eli Zaretskii wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:86frgrzlwi.fsf@HIDDEN">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">Date: Sun, 25 May 2025 18:19:20 -0500
From: Rick <a class="moz-txt-link-rfc2396E" href="mailto:rbielaws@HIDDEN">&lt;rbielaws@HIDDEN&gt;</a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:78582 <at> debbugs.gnu.org">78582 <at> debbugs.gnu.org</a>

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.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">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 .
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Please show a full recipe using nonincremental-search-forward, and I
will try it.

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">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.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
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.
</pre>
    </blockquote>
  </body>
</html>

--------------SsUHN29cQE9WeImXgFkUFXhT--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 26 May 2025 16:22:02 +0000
Resent-Message-ID: <handler.78582.B78582.174827649816502 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78582
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Rick <rbielaws@HIDDEN>
Cc: 78582 <at> debbugs.gnu.org
Received: via spool by 78582-submit <at> debbugs.gnu.org id=B78582.174827649816502
          (code B ref 78582); Mon, 26 May 2025 16:22:02 +0000
Received: (at 78582) by debbugs.gnu.org; 26 May 2025 16:21:38 +0000
Received: from localhost ([127.0.0.1]:58610 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uJaa1-0004I2-Hj
	for submit <at> debbugs.gnu.org; Mon, 26 May 2025 12:21:37 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:43424)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uJaZz-0004He-QC
 for 78582 <at> debbugs.gnu.org; Mon, 26 May 2025 12:21:36 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1uJaZt-00081J-WA; Mon, 26 May 2025 12:21:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=bBHABnQknw3JwjfDmFg9hdHsd3uJwaNcr3fH1gCPqcI=; b=asgjmuZdw8ot
 3hFR8JF3SyktPKeMxf/jLh+4Swew6YCjofXF5ayQdbb6xEkdsvWCq0XCSArPWJyRGTQMNCV8WRb/s
 JKVlZoNQnsNY7AESBQFxiDNNKrSlbWVXqedH9I1eKxR/mBpsPrFoc0j606STwTF0dS4q/78nEO4MB
 Mru4UlHRTYolRtSwf9HDqgwZlkCacnmRN3EcQjfOYfOR+3CKCHSP+3IgmQQ/mf0/RIgsLyrDGrjCI
 xCVUmZC/vE5C6O8f86Oj9HN0ZBx9Ao0uXKNpUdODFYzBHFqKD7KFUUzJmT3fFByP3MWcEXkyqSIha
 idClDpNWxku9VwVwjmzuDw==;
Date: Mon, 26 May 2025 19:21:08 +0300
Message-Id: <861psbz6kr.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <7f0afc3e-1e34-4c56-880d-ffad33259f5d@HIDDEN> (message from
 Rick on Mon, 26 May 2025 10:36:52 -0500)
References: <d2414b0f-dde0-4c93-bffd-06fc241327a9@HIDDEN>
 <86sektz03q.fsf@HIDDEN> <592d5998-c453-444b-9c02-b71f331b6f9b@HIDDEN>
 <86frgrzlwi.fsf@HIDDEN> <7f0afc3e-1e34-4c56-880d-ffad33259f5d@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 26 May 2025 10:36:52 -0500
> Cc: 78582 <at> debbugs.gnu.org
> From: Rick <rbielaws@HIDDEN>
> 
> 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.

Thanks.  This doesn't reproduce the problem on my system.

So now I suspect that your Emacs has some local changes that are not
in upstream.  Is that possible?  Your build details:

  In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,
   cairo version 1.18.0) of 2025-05-11 built on lcy02-amd64-059
  Repository revision: 9328fd1ab06a1a1f85077fd1caadf9128c90f6c1
  Repository branch: master
  System Description: Ubuntu 24.04.2 LTS

are strange: on the one hand this says version 30.1, but OTOH the
branch is 'master' (which is not the branch from which Emacs 30.1 was
delivered), and the commit SHA is not a commit our Git repository
knows about.  What repository did you use to build, and could it be
that it has some local changes?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Resent-From: Rick <rbielaws@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 26 May 2025 17:24:02 +0000
Resent-Message-ID: <handler.78582.B78582.17482802312010 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78582
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 78582 <at> debbugs.gnu.org
Received: via spool by 78582-submit <at> debbugs.gnu.org id=B78582.17482802312010
          (code B ref 78582); Mon, 26 May 2025 17:24:02 +0000
Received: (at 78582) by debbugs.gnu.org; 26 May 2025 17:23:51 +0000
Received: from localhost ([127.0.0.1]:59081 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uJbYF-0000WM-9d
	for submit <at> debbugs.gnu.org; Mon, 26 May 2025 13:23:51 -0400
Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]:54659)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <rbielaws@HIDDEN>)
 id 1uJbYD-0000W1-LB
 for 78582 <at> debbugs.gnu.org; Mon, 26 May 2025 13:23:50 -0400
Received: by mail-io1-xd34.google.com with SMTP id
 ca18e2360f4ac-85de3e8d0adso52774939f.1
 for <78582 <at> debbugs.gnu.org>; Mon, 26 May 2025 10:23:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1748280224; x=1748885024; darn=debbugs.gnu.org;
 h=content-transfer-encoding:in-reply-to:from:content-language
 :references:cc:to:subject:user-agent:mime-version:date:message-id
 :from:to:cc:subject:date:message-id:reply-to;
 bh=lF+d2SRJsyxfYH8sD6O2E1+uviOQwQDtGlzgMUPSudQ=;
 b=OrF4nuYacbKpgLrKenhIe2ueFuTb/U/G2bZTqnin+tvlNVsM57Xm9RoXB9xde6R2hD
 gXEODEwSRvK6JImEtwBnbcx70XMD7AVIqCFPK16FoLr6k+PELfujvOsU9GNzhB5IU3Gb
 8UzakC513iYQ1YPq4hEvRG66JHrfIuZWehjjLJscXo0AqfRUrO32Rc234+TlTkqn6nq2
 ld9X6zX9wP50reJsWdT06ZILTXcMl4xsq3je2hvxSbco40xW6I1vXhPnaWKjhB8rkq4W
 FAVYI6rldYbW8O6xIqJkIOciAMm+sqdM+OXY8b1KxYAArEI/QuZ8IWzH0O96IacFq8MB
 LA7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1748280224; x=1748885024;
 h=content-transfer-encoding:in-reply-to:from:content-language
 :references:cc:to:subject:user-agent:mime-version:date:message-id
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=lF+d2SRJsyxfYH8sD6O2E1+uviOQwQDtGlzgMUPSudQ=;
 b=HG4mqK/1yPDn5qjHwD6ENey1U+AlckKYP6y4JG5/RpcYsHzoBkdF6QU/zp2AX0HEo3
 aQUxy9PCpR/gb6+w5ecpcXPKFab/phwrpCL7HS3Qic7g44MLxF/l9a9OKizdsdg/O58d
 bDIj6FzKBzm7qpAlD8xg9tnUWfz/ROL1Czom//MEHJ0dFrJ9m5+xkBu2pE75JsbbjSAF
 NMYpOsoO489Yfxv5fiAwZJSBzujsCNSwulM8vlkA07c2/hcPFv5iZUQ5WRDYOSdY1JpL
 LicnZuqyLLFJnQPQhAQHuAHC20ktpzniVw7wgnZsxUc27bFM9uTzYeH2XiYrSTMEnlAv
 6hsw==
X-Gm-Message-State: AOJu0YwKbNwiEV7MHP0Vh8YrOUwLeTSKlQ3vDY3/FbP35izqDcvv1yr7
 FL0vvg1erU1T2G7uiFko/4JemcltFcwEKWiSlHk5qq2gR+IoF3R47wDeKFT9nw==
X-Gm-Gg: ASbGncug4MGixAVQxavpZshWUJyaB23/IIeQhktjyDK0OqPSJ5N07/O49dhRFkLtye3
 Xg0Yx91HWuCmDyDVF5PkBC1QZOizWVmJwl0tZL8Rsjo+QKE0lJiAOzcyf5npdtXSXFI5ycqg8t2
 +e9VT4PeAYWtVjdSQ8+jfHAQJMW2fSQz1jzmXVOQOoWWBza4/Y4tAPZkcl5UvadLkqxByQ7Fcus
 2/spWC8uxu0DWgSv/zs9x/TQIfNeLiX1ukBiiUCPSmxktIXJSQb/7IB49jaW+qiilFDT3VFlVeQ
 lLZXh84+Z65+fzF6H0zFcwRi1ryDfAvMEQ223RlZCAfnh2fWXbHoDJZXj4boabmeXZE+il5ofed
 6hQUJNyDfqqI53wqFtr0=
X-Google-Smtp-Source: AGHT+IEkY9zq0F72tAbmZUHlIZpZ5xj+2g0zXOalv7s1mdlnO/eo8dguvYPzYLxYeyz9kqja2ZThvA==
X-Received: by 2002:a05:6602:481a:b0:864:68b0:60b3 with SMTP id
 ca18e2360f4ac-86cbb8c26efmr1182304039f.12.1748280223571; 
 Mon, 26 May 2025 10:23:43 -0700 (PDT)
Received: from ?IPV6:2601:447:c580:e8e0:603:b751:5f78:3c46?
 ([2601:447:c580:e8e0:603:b751:5f78:3c46])
 by smtp.gmail.com with ESMTPSA id
 8926c6da1cb9f-4fbcc38c50asm4787661173.2.2025.05.26.10.23.43
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 26 May 2025 10:23:43 -0700 (PDT)
Message-ID: <36d30424-80b0-43c3-b55c-2fdb7dbd1fbd@HIDDEN>
Date: Mon, 26 May 2025 12:23:42 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <d2414b0f-dde0-4c93-bffd-06fc241327a9@HIDDEN>
 <86sektz03q.fsf@HIDDEN> <592d5998-c453-444b-9c02-b71f331b6f9b@HIDDEN>
 <86frgrzlwi.fsf@HIDDEN> <7f0afc3e-1e34-4c56-880d-ffad33259f5d@HIDDEN>
 <861psbz6kr.fsf@HIDDEN>
Content-Language: en-US
From: Rick <rbielaws@HIDDEN>
In-Reply-To: <861psbz6kr.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

I used App Center on this Ubuntu machine to find and install Emacs via Snap.

The Snap description includes this:

This snap is built via the build.snapcraft.io service from the 
snapcraft.yaml definition at https://github.com/alexmurray/emacs-snap to 
ensure source and build transparency.

They make no mention of anything custom on their site.
Since neither you nor several people on StackExchange can recreate the 
problem, I will report the issue to the build maintainer on GitHub.


On 5/26/25 11:21, Eli Zaretskii wrote:
>> Date: Mon, 26 May 2025 10:36:52 -0500
>> Cc: 78582 <at> debbugs.gnu.org
>> From: Rick <rbielaws@HIDDEN>
>>
>> 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.
> Thanks.  This doesn't reproduce the problem on my system.
>
> So now I suspect that your Emacs has some local changes that are not
> in upstream.  Is that possible?  Your build details:
>
>    In GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,
>     cairo version 1.18.0) of 2025-05-11 built on lcy02-amd64-059
>    Repository revision: 9328fd1ab06a1a1f85077fd1caadf9128c90f6c1
>    Repository branch: master
>    System Description: Ubuntu 24.04.2 LTS
>
> are strange: on the one hand this says version 30.1, but OTOH the
> branch is 'master' (which is not the branch from which Emacs 30.1 was
> delivered), and the commit SHA is not a commit our Git repository
> knows about.  What repository did you use to build, and could it be
> that it has some local changes?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 26 May 2025 18:34:01 +0000
Resent-Message-ID: <handler.78582.B78582.174828438421393 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78582
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Rick <rbielaws@HIDDEN>
Cc: 78582 <at> debbugs.gnu.org
Received: via spool by 78582-submit <at> debbugs.gnu.org id=B78582.174828438421393
          (code B ref 78582); Mon, 26 May 2025 18:34:01 +0000
Received: (at 78582) by debbugs.gnu.org; 26 May 2025 18:33:04 +0000
Received: from localhost ([127.0.0.1]:59561 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uJcdA-0005Yf-RA
	for submit <at> debbugs.gnu.org; Mon, 26 May 2025 14:33:04 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:39092)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uJcd8-0005YG-GP
 for 78582 <at> debbugs.gnu.org; Mon, 26 May 2025 14:32:58 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1uJcd3-0000sE-62; Mon, 26 May 2025 14:32:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=bRWd+nJKUL8MtFL3+TNG9Qw85BrxRyRFvM0Vm1ck7WI=; b=H9UPgvLlaDLu
 WWhgL25JlVvRvIrDxTEHae6L3upQbACwDDowSngR0ZW4ivOSglqxV3ZrYkUJqBDlWAfnbvhJabN3R
 +YaulqI0yct9LAxpzXcXgrovuoP2rtIoCkUMNF4WahDoyMy46Kz0xNlLDNXdT2tMbez0laKp6It0I
 0kyb2MSDxmirWSM4dJwqJskLl1wSeoUNbyYdDay79ojV6x+lasGLfYKEShHGfDqGAcOzLUlNYW5vO
 csd7Ftwke88xDXSzYJmC3GeXJmvhvqjg68neLh4fP8UsI/lqnbyLS+Hc1J1IOJnKYMjfXc9gndo/L
 5zpqanJ7dmIiZ+nMR5biZw==;
Date: Mon, 26 May 2025 21:32:51 +0300
Message-Id: <86sekrxlws.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <36d30424-80b0-43c3-b55c-2fdb7dbd1fbd@HIDDEN> (message from
 Rick on Mon, 26 May 2025 12:23:42 -0500)
References: <d2414b0f-dde0-4c93-bffd-06fc241327a9@HIDDEN>
 <86sektz03q.fsf@HIDDEN> <592d5998-c453-444b-9c02-b71f331b6f9b@HIDDEN>
 <86frgrzlwi.fsf@HIDDEN> <7f0afc3e-1e34-4c56-880d-ffad33259f5d@HIDDEN>
 <861psbz6kr.fsf@HIDDEN> <36d30424-80b0-43c3-b55c-2fdb7dbd1fbd@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Mon, 26 May 2025 12:23:42 -0500
> Cc: 78582 <at> debbugs.gnu.org
> From: Rick <rbielaws@HIDDEN>
> 
> I used App Center on this Ubuntu machine to find and install Emacs via Snap.
> 
> The Snap description includes this:
> 
> This snap is built via the build.snapcraft.io service from the 
> snapcraft.yaml definition at https://github.com/alexmurray/emacs-snap to 
> ensure source and build transparency.
> 
> They make no mention of anything custom on their site.
> Since neither you nor several people on StackExchange can recreate the 
> problem, I will report the issue to the build maintainer on GitHub.

Thanks.  Please ask them whether they have any local changes wrt the
upstream Git repository, and also on what revision of the upstream
repository is the version you have based.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
References: <d2414b0f-dde0-4c93-bffd-06fc241327a9@HIDDEN>
In-Reply-To: <d2414b0f-dde0-4c93-bffd-06fc241327a9@HIDDEN>
Resent-From: Alex Murray <murray.alex@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 27 May 2025 01:00:02 +0000
Resent-Message-ID: <handler.78582.B.174830754815041 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78582
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: eliz@HIDDEN, 78582 <at> debbugs.gnu.org
X-Debbugs-Original-To: eliz@HIDDEN, bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.174830754815041
          (code B ref -1); Tue, 27 May 2025 01:00:02 +0000
Received: (at submit) by debbugs.gnu.org; 27 May 2025 00:59:08 +0000
Received: from localhost ([127.0.0.1]:34242 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uJiep-0003uV-VL
	for submit <at> debbugs.gnu.org; Mon, 26 May 2025 20:59:08 -0400
Received: from lists.gnu.org ([2001:470:142::17]:34414)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <murray.alex@HIDDEN>)
 id 1uJien-0003tV-7B
 for submit <at> debbugs.gnu.org; Mon, 26 May 2025 20:59:05 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <murray.alex@HIDDEN>)
 id 1uJieh-0000iO-Id
 for bug-gnu-emacs@HIDDEN; Mon, 26 May 2025 20:58:59 -0400
Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <murray.alex@HIDDEN>)
 id 1uJiee-0003an-7z; Mon, 26 May 2025 20:58:59 -0400
Received: by mail-ed1-x52b.google.com with SMTP id
 4fb4d7f45d1cf-6049431b0e9so2276258a12.0; 
 Mon, 26 May 2025 17:58:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1748307533; x=1748912333; darn=gnu.org;
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=jMBU2Wyqq3BypeYAIQgcOUn8fttNfqkBw2BpeNJEOkY=;
 b=UG8O+E3Z9noCTdL6aWykZSbXRygAnSNgY1FLBzvMRWvt7m+hApCFC7zMu2Ei70Tffg
 AREMJr87Yuw1CqdDS0v+sTVwWimRSXTsCwQHF+YRaPaw6JbWinfcTf+ZF7eXrN6Kvj8B
 PyqRf94/I9U4rS482wKdKD/i6AscvB/TR0rOQaQSsHmoclAEBpyT+5o2X+NDRTyeGrVn
 0clzLSTgtJbaDyXJLi28tsRrcLiBUjajwFn+XMi34ynB2lErdVqHCK9hHKuC5J1cpPNH
 gCALQGvDytQU8HVC1YAbWXcrKtu/aK9hz02Jg87Z4WfNVbbXDBVZ53ywcVZWRXOt8K/Z
 kzsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1748307533; x=1748912333;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=jMBU2Wyqq3BypeYAIQgcOUn8fttNfqkBw2BpeNJEOkY=;
 b=wwfVaGpb4rGwY31esbDyJDZopDKvzRx0WpUeWl4PHcO60EHwbcBuKY7A5ey1mAlrv5
 2hRymQXuLgKrvTFtMXg6nh06HexxYOLmgtkNkqmst/yYKY9d/I4bDjQvExMe0n9K5CNP
 lijuHqvK3lDAKmd5NmhAguPVv+qR7gvD3HZEszpA+8sucrnEWsgeGxq5GdjgiOMFUnhm
 kamEPelN0GyLPJ9QQGS1xKwIp08p2iy3wcThEWbrGOyjZb6plRaqEddz8IdmKOmhpaKm
 czUz4Uzuk648k9SsW8nZ1F8Y7JDObBYlr6XzSornI+vEZ+EpB12MsEM/5NfcnGQE9KOL
 I+xA==
X-Forwarded-Encrypted: i=1;
 AJvYcCXnLODsXtWepZ/3yRnRruNFZos4h9leG7da/iFvxT5KsVXv5dQd06ZjIh8LAwq+OxwUHJ/ZBE/NXDgxvz1v@HIDDEN
X-Gm-Message-State: AOJu0YxCCBi6m+7ifLDAPTh3eHSNm5WgFT2HkJ+s86IAvmhviqquWiZ2
 rZy40oprmRnTpDDgyMaRTyw7vUn49ydddNdf4M/GpC3aw53WtuhWKj/ukRDk3Dw9/ETsVNTl5sb
 bSF2WD0Hh0N0dxI5VEbKq/fMWAJOlIBO3Pseh
X-Gm-Gg: ASbGncs1vcH0dPTT1C/ia8M2ttLZemYnsykmmDeecp8fNaVTYeM7WiW5ekbNuaJvbu8
 JGikJ0UDz+hrYIW9/a2fcEuapQMCWw1Ub+G2oTkCUPh7vXKmwMXZcwWJfMmSlYKoVvkcD/PjULq
 a9nBvzmTwLB58LUGGl2JEnLG9ZFL7duDiiCZVt4wU70qFNAo0zMCnaIzP4P3fvcIX1Lbispp++M
 Q==
X-Google-Smtp-Source: AGHT+IFHxdHYiNCmVKgNb+m64E+JHhlDXi39wt0nr9O9L+YYBFPhAxbSyjylgxy/Gs7ImBSnXkpiHigrWTl/HjJH3gY=
X-Received: by 2002:aa7:c389:0:b0:602:e002:791e with SMTP id
 4fb4d7f45d1cf-602e0027a76mr7291565a12.0.1748307532995; Mon, 26 May 2025
 17:58:52 -0700 (PDT)
MIME-Version: 1.0
From: Alex Murray <murray.alex@HIDDEN>
Date: Tue, 27 May 2025 10:28:36 +0930
X-Gm-Features: AX0GCFuAVW4tvznrVUnqzShLh7m4pgQTk5d_KacztZY172LPbk2x0X7Nv52X8-I
Message-ID: <CAA6Afg5yz9xRG7Ro0xq5V9k_V-AJSAnV4saxqXf9QHyYc10oKQ@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=2a00:1450:4864:20::52b;
 envelope-from=murray.alex@HIDDEN; helo=mail-ed1-x52b.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

Hi folks

Upstream maintainer of emacs-snap here.

I have just had this issue brought to my attention via
https://github.com/alexmurray/emacs-snap/issues/106 - thanks Rick.

To provide some more context - the emacs-snap carries a few
customisations to work around issues with the nature of the snap
execution environment and to try and ensure the correct library paths
etc are used in various places (since a snap is designed to operate on
any given Linux system, not just the one it was compiled on).

These are achieved by a mix of some site-lisp and some patches to the
source code directly and a short C program that runs before the emacs
binary itself is executed to ensure things like the GTK environment
and fonts etc are all respected from the users machine.

All of these are maintained at
https://github.com/alexmurray/emacs-snap/ - you will see a small C
program, 3 different patch files and the site-lisp which can be
summarised as follows:

setup-env is the small C program to set the GTK environment and other
associated bits etc to ensure that the emacs snap respects the host
systems GTK settings etc (even if it is a different GTK version etc)
and which then exec's the emacs binary itself

native-comp.patch - to ensure native-comp uses the compiler that the
emacs snap itself was compiled with rather than the one on the host
system
treesit.patch - similarly, to ensure when compiling tree-sitter
modules that they use the same compiler and libc etc as the emacs-snap
itself uses
emacs-x-resource-name.patch - always set the x resource name to
"emacs" to ensure that GNOME can associate the process with the right
desktop file

The site-lisp bit just unsets some environment variables that got set
by the setup-env program to ensure that any process that the
emacs-snap executes doesn't get confused about the environment it is
running in (since in general these will need to use the host systems
settings, not the ones from the emacs-snap).

On the surface of it, none of these changes would appear to me to be
causing this issue, however clearly there is a bug here that only
affects the emacs snap so I am quite keen to try and resolve it.

However, whilst I can reproduce it using the instructions provided by
Rick I am at a bit of a loss as to what to do next to try and debug it
- if anyone can give any hints or ideas that would be greatly
appreciated.

Thanks,
Alex

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 27 May 2025 11:21:02 +0000
Resent-Message-ID: <handler.78582.B78582.174834483814230 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 78582
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Alex Murray <murray.alex@HIDDEN>
Cc: 78582 <at> debbugs.gnu.org
Received: via spool by 78582-submit <at> debbugs.gnu.org id=B78582.174834483814230
          (code B ref 78582); Tue, 27 May 2025 11:21:02 +0000
Received: (at 78582) by debbugs.gnu.org; 27 May 2025 11:20:38 +0000
Received: from localhost ([127.0.0.1]:39319 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uJsMI-0003hR-AP
	for submit <at> debbugs.gnu.org; Tue, 27 May 2025 07:20:38 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:51272)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uJsME-0003h0-8x
 for 78582 <at> debbugs.gnu.org; Tue, 27 May 2025 07:20:35 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1uJsM8-0008If-68; Tue, 27 May 2025 07:20:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=JPEnO+DsuS5fPH70L4ZjgyxFFX8L5VLezmc2zML3qek=; b=SNag//vCSd9t
 yeWSOCFZANOdlLkQ7zGUQSSjcOWo2MhAfhtcNXuRDaeayXRDeWOCF+m/3Czt01W8yWMowMtFhbKdJ
 /8ui40uRc5nOjcFzhB7dAQN/OAAoJw4rLAl0StWCJZCn0PDi1XoKJvxmESWbuCqCz0mIErG3Wmikd
 6mQ3Z2w8DIOK69YnLSHB0UP54itWnIbbQUIFmeOJZ60TErw9v+OZvP0Wcr2cxMllNrZra8ISD6ugL
 M5XWs2fwkQfMYO6LNfV2PgG3ekBuJD9w+HXfxQ9jjv6EWCTWfrVU3OaRYw58jJoaDAwk/zzsKS35S
 mB0VGt8R9MI0AVDd+sDBDQ==;
Date: Tue, 27 May 2025 14:20:23 +0300
Message-Id: <86jz62xpu0.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CAA6Afg5yz9xRG7Ro0xq5V9k_V-AJSAnV4saxqXf9QHyYc10oKQ@HIDDEN>
 (message from Alex Murray on Tue, 27 May 2025 10:28:36 +0930)
References: <CAA6Afg5yz9xRG7Ro0xq5V9k_V-AJSAnV4saxqXf9QHyYc10oKQ@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Alex Murray <murray.alex@HIDDEN>
> Date: Tue, 27 May 2025 10:28:36 +0930
> 
> Hi folks
> 
> Upstream maintainer of emacs-snap here.
> 
> I have just had this issue brought to my attention via
> https://github.com/alexmurray/emacs-snap/issues/106 - thanks Rick.
> 
> To provide some more context - the emacs-snap carries a few
> customisations to work around issues with the nature of the snap
> execution environment and to try and ensure the correct library paths
> etc are used in various places (since a snap is designed to operate on
> any given Linux system, not just the one it was compiled on).
> 
> These are achieved by a mix of some site-lisp and some patches to the
> source code directly and a short C program that runs before the emacs
> binary itself is executed to ensure things like the GTK environment
> and fonts etc are all respected from the users machine.
> 
> All of these are maintained at
> https://github.com/alexmurray/emacs-snap/ - you will see a small C
> program, 3 different patch files and the site-lisp which can be
> summarised as follows:
> 
> setup-env is the small C program to set the GTK environment and other
> associated bits etc to ensure that the emacs snap respects the host
> systems GTK settings etc (even if it is a different GTK version etc)
> and which then exec's the emacs binary itself
> 
> native-comp.patch - to ensure native-comp uses the compiler that the
> emacs snap itself was compiled with rather than the one on the host
> system
> treesit.patch - similarly, to ensure when compiling tree-sitter
> modules that they use the same compiler and libc etc as the emacs-snap
> itself uses
> emacs-x-resource-name.patch - always set the x resource name to
> "emacs" to ensure that GNOME can associate the process with the right
> desktop file
> 
> The site-lisp bit just unsets some environment variables that got set
> by the setup-env program to ensure that any process that the
> emacs-snap executes doesn't get confused about the environment it is
> running in (since in general these will need to use the host systems
> settings, not the ones from the emacs-snap).
> 
> On the surface of it, none of these changes would appear to me to be
> causing this issue, however clearly there is a bug here that only
> affects the emacs snap so I am quite keen to try and resolve it.
> 
> However, whilst I can reproduce it using the instructions provided by
> Rick I am at a bit of a loss as to what to do next to try and debug it
> - if anyone can give any hints or ideas that would be greatly
> appreciated.

Thanks for reaching out.

Can you tell when you last synced with the upstream Git repository,
and with which branch?  Looking at your latest commits, it seems the
answer is Feb 24 and emacs-30, respectively, but is that correct?

If you build the upstream version of Emacs without your local changes,
do you still see the problem with Rick's recipe?

If the upstream build still shows the problem, I'd say take a look at
your build environment, including libraries and the toolkit you use.
The command "C-h l" should show the keys read by Emacs, so maybe try
that in both scenarios to see what Emacs saw as keyboard input.

Last modified: Tue, 27 May 2025 11:30:02 UTC

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