From unknown Sat Jun 14 00:06:41 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#78582 <78582@debbugs.gnu.org> To: bug#78582 <78582@debbugs.gnu.org> Subject: Status: 30.1; which-key-mode overwrites custom key bindings Reply-To: bug#78582 <78582@debbugs.gnu.org> Date: Sat, 14 Jun 2025 07:06:41 +0000 retitle 78582 30.1; which-key-mode overwrites custom key bindings reassign 78582 emacs submitter 78582 Rick severity 78582 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat May 24 17:16:45 2025 Received: (at submit) by debbugs.gnu.org; 24 May 2025 21:16:45 +0000 Received: from localhost ([127.0.0.1]:36794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uIwEW-0007wI-Qn for submit@debbugs.gnu.org; Sat, 24 May 2025 17:16:45 -0400 Received: from lists.gnu.org ([2001:470:142::17]:38492) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uIwET-0007vl-Su for submit@debbugs.gnu.org; Sat, 24 May 2025 17:16:42 -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 ) id 1uIwEI-0002CU-BB for bug-gnu-emacs@gnu.org; Sat, 24 May 2025 17:16:35 -0400 Received: from mail-io1-xd2b.google.com ([2607:f8b0:4864:20::d2b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uIwEF-0007E8-S0 for bug-gnu-emacs@gnu.org; Sat, 24 May 2025 17:16:30 -0400 Received: by mail-io1-xd2b.google.com with SMTP id ca18e2360f4ac-867347b8de9so63843539f.0 for ; Sat, 24 May 2025 14:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748121386; x=1748726186; darn=gnu.org; h=subject:from:content-language:to:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=yGzb3Z49MQfG4/PoA4KWGIP/7AI8BsgJmkDeXG3Y4g0=; b=G4no+tozxD1F6ZXr7qRWxzyvm+UOxfPn1esCk1/ICr5rZ4BMOQlCvH6WssAyLA434v AsCe73NjK/OBG1O5nFS4R96iI9OBgggcyl93UNcQAG9yWjVA2Deflj9fTt5rSePVFno3 yrOPInnuehF2CeZQkXg9DEFu6zw8Nfbl7BpHq8ZMIuuqCtqv7+tTShpV4Zc5xdIJOeKC blHblkk3mZAngxJ4wl0iJfBdzqgEuFqnWf+SoNZUqNBhtYCqqO2dKYfduxTeBcbOh0ZI jjqFsrW6eWDotJ2IwfB4hKAq3xtMIrgprsJuBoh0ae6CGr26da9Ivqt9n0h2yXxP2eiy G4FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748121386; x=1748726186; h=subject:from:content-language:to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yGzb3Z49MQfG4/PoA4KWGIP/7AI8BsgJmkDeXG3Y4g0=; b=AiN2qx/dcw2/4R9ZbTeWK+F/g3MSNcCwv2GoriQvOP3FPxER5w73KukUKv2Bg7gEaN KtdkpcRHonEGU4vKvnIyAY7+f/T9h6C3gSJWkUR2G2lepHE08YU+Yq+KhGHnOO108OqE ahQOBmJUgBwq76rGEGMA/B7vrsZumBtrC997XeW/78+ftg+eBayyZTvBR0lO231VZE/i ZzjDJ0tPyiEB1zFFGl/cuBsuk05KYlD6ot7TCyns3T23oDnIHsc4nGbRtK7dggS+Hx5x //iQ1Z02+ZoX4/rv42nnqPuvs+icj0StVmoJr75jT5c22K3m4E5cOnWFStFeoY7Mq8Du LGYw== X-Gm-Message-State: AOJu0YwUCJmIglAgD59FrXAgWtTQwulPhSyC7xtq9YUF478TFcze/Nr+ JD9CHoP+R92HF5u+jyr3muM3t4tWN0IMPCWYIlG2k3xqV03lU/p+x7Euli7XdQ== X-Gm-Gg: ASbGnctgXHCxt60VZ+sUoo6SbJFA0srfiXyjYW5QlEHyty9/lIt3toJLcbOGogGLFGI ihjfVlfgGa5uAnAfYaQlAGlj2BZPdFMYa90+S43YijIUx9qdLuxKzih+kV0wre41Dr+7yL76FpG V1KvlcWTcb+sdAnEuc5FqVUs5EnCEVIdS6vZ86nH5KUowU393lCWjLfLKJ4LpjbIfjzKjzzOwHY 3tge4H+jWDrS9fXHsKqNZRhEWTOVLlfuTtbK6yzymF5iVshKqqv1Zumlw8xPA8kK6CJdZSU3E7g EUDA2TSmM77dbU5y943TavB9kUePfX2LVK7eIy23WKqU6sikc2FQLeFQQQkNZ8mPcnKPZfER9y+ EN7TP8itrbZxqYHCpPIfPQg== X-Google-Smtp-Source: AGHT+IGQGpLrWuyiALr1/OX8a5VBYtFXiC/9AzVwNIzcnC95u9QfTyxim0QePvTLVN4ewVVFeOX9rA== X-Received: by 2002:a05:6602:4f87:b0:867:15a5:d16 with SMTP id ca18e2360f4ac-86cade1735bmr575243739f.8.1748121385666; Sat, 24 May 2025 14:16:25 -0700 (PDT) Received: from ?IPV6:2601:447:c580:e8e0:ea9d:a7ed:a7ab:f97b? ([2601:447:c580:e8e0:ea9d:a7ed:a7ab:f97b]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4fbcc3de827sm4221398173.73.2025.05.24.14.16.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 May 2025 14:16:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------04OD0O1wVrqV9rgTd1tkxCeX" Message-ID: Date: Sat, 24 May 2025 16:16:23 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: bug-gnu-emacs@gnu.org Content-Language: en-US From: Rick Subject: 30.1; which-key-mode overwrites custom key bindings Received-SPF: pass client-ip=2607:f8b0:4864:20::d2b; envelope-from=rbielaws@gmail.com; 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-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 
--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-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 25 02:16:47 2025 Received: (at 78582) by debbugs.gnu.org; 25 May 2025 06:16:47 +0000 Received: from localhost ([127.0.0.1]:41114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJ4f9-0005UJ-4e for submit@debbugs.gnu.org; Sun, 25 May 2025 02:16:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54536) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uJ4f5-0005Tb-60 for 78582@debbugs.gnu.org; Sun, 25 May 2025 02:16:43 -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 ) id 1uJ4ez-0002m2-F0; Sun, 25 May 2025 02:16:37 -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=nmjShnsgp5gLpomm71zcUXStlQW1kDFjb2U+i1UrBmg=; b=a9Oe24CRTsTa rTdKPhGDdPyhwvcv67uG6LHjbVOUkOgipJ1KpWegVeDChwBYia4D1Tm/XLCGu/FB7SufNjEMWw8tn 9oSKK1j1c6ckVrlUFPvo1EhSQAH7iOEw7SiLcIDBoM3BsqxGO+8ioYKvL67054DPbaRkWWKpILziH etR7kw4Mxpz08i+Xpgk8xXEOa4TIjD/5kdsoC+70nqNx7TGWi8II3RPR3xmjCu5nzBnbbxs274Et3 bP6G1sVlNQP4psld0Yn3lqaJLKmzoOBU+eJK1uGfiKYPli6j1xTXw4ShTCk1sUrn61fFtusE91Ur0 5TzVhy3/vcn9K5izFpCJ5A==; Date: Sun, 25 May 2025 09:16:25 +0300 Message-Id: <86sektz03q.fsf@gnu.org> From: Eli Zaretskii To: Rick In-Reply-To: (message from Rick on Sat, 24 May 2025 16:16:23 -0500) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 24 May 2025 16:16:23 -0500 > From: Rick > > 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? From debbugs-submit-bounces@debbugs.gnu.org Sun May 25 19:19:34 2025 Received: (at 78582) by debbugs.gnu.org; 25 May 2025 23:19:34 +0000 Received: from localhost ([127.0.0.1]:50096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJKcv-0006aB-AA for submit@debbugs.gnu.org; Sun, 25 May 2025 19:19:33 -0400 Received: from mail-il1-x12b.google.com ([2607:f8b0:4864:20::12b]:60497) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uJKcq-0006Ze-Ez for 78582@debbugs.gnu.org; Sun, 25 May 2025 19:19:29 -0400 Received: by mail-il1-x12b.google.com with SMTP id e9e14a558f8ab-3da73998419so5643685ab.0 for <78582@debbugs.gnu.org>; Sun, 25 May 2025 16:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748215162; x=1748819962; darn=debbugs.gnu.org; h=in-reply-to:content-language:references:cc:to:subject:from :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=qlZxKs4e0tnb9zBSKmlqkTxnQw2LKUfGbULi81blV5Y=; b=Lp964yjj/vkSD5SpZK9N0sYevvFZ2SxIaBtB/wnuty9NyQKdBhmnRI/KauOg+O1jDG pPjuGaKh22kZqeCfjhgSUf8qsF31qMsnOTlZraYe1LW18IJurW3gy6ulmVN0y3fMmS3X xqxyUY7e+32RRqe+LTgy+8HX4qRoVY9GAU3ddI6v2/bqNLGEN4B+p4UAcOd32D39d/Xi CvblO626qUSov7W4A8QVloD0ymLrqx2chSKre9Lr17Jgs1QbstgFzR1pKPCmcFHsKSsm UXQ4llAlV+GZs2l6AJ4voGKN3DYFK0yAG3voY1AlUn3Lb21wTD6H2IG1tSHfIGvz2H5P Qiow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748215162; x=1748819962; h=in-reply-to:content-language:references:cc:to:subject:from :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=qlZxKs4e0tnb9zBSKmlqkTxnQw2LKUfGbULi81blV5Y=; b=VMHOpGMsWxILV6DJEb9gRBqNnY15ETSUGn+G141rCuA9Oir59MpLijllFoadpPJd5r f59scbGlVc1Sd0x3A0ZvmwZRGiLHAzWRVGhB9fAXbeVH9PT4zY7iojgyA73KMktENaTd xPmlMdgerG3Mzk7HxKxvTzZaCns+EFr9iEO9RBpCc41dZtPxhp63LU0tXhNhhKZCwWPv aWUF5y1P4dpxpTDp1jOR1UVd+LrIqZWBQ1EKBaIDGGRYQLUFIDUCG/g3TG8KN9XmfMAA U17URxKt/lMVhYfWNZWeCa2YYyQw96Odl/tIofK3xl1F7M71HQOxkQo67mFh9rREOOaA h05Q== X-Gm-Message-State: AOJu0Yw5o3t4hIOOe7ZTOBDnnUR7z+Bztdn3H4e5wzKicRB1f2C5SJUt R8d0zOR0p7lFcvh7R1niY9Bg6ucKhMtj9iIqE3ath2k3cZG+zF/RjNdp X-Gm-Gg: ASbGncu6OAZeO68/kQkdyguAxOm40upFLHc3tR2/GDlugW/CihCfcDvs9rQ9S+szElg lhVQd76+KXYNadItYFPGhJntRYMiCbPLFqfEqmxiinPOMOwf5DoyaUSlRXY3KbiD2kc8H8o0zxn 5Zf0y9ne/i/tu8caWHD31CSwqzaFUfClTNwJde2VcQLx3QYsDNhM0Q0kIOI+yIx1tsGbuGTZv8k LMSA9F6RioOdN5yuSqPD9+hJRVlGgGrAFUx8usDFvujfzeZNm1DLPuz/MMvWKoBMibX2rwBJxQm 3BHnFaAI4zjq3IC/k0Z+V/T/kZ/qPyMpYpqRSJTcfWJdKv1qGZvDDKacGtGtOGrkFprHr2+seBw 1sqgCZCuG/eC9DMjTi0+tSQsmrTkgdKnk X-Google-Smtp-Source: AGHT+IEH6EowwIX7y53WnbFNirr22gxywTWrZHpoJxBh93w4xeKXXB/hohm4AT9+U0Sv3VEnIK2/TA== X-Received: by 2002:a05:6e02:152a:b0:3dc:87c7:a5b1 with SMTP id e9e14a558f8ab-3dc9b670da1mr57756445ab.4.1748215162197; Sun, 25 May 2025 16:19:22 -0700 (PDT) Received: from ?IPV6:2601:447:c580:e8e0:3b15:ffee:9fe1:ae48? ([2601:447:c580:e8e0:3b15:ffee:9fe1:ae48]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4fbcc38a2b1sm4508063173.8.2025.05.25.16.19.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 May 2025 16:19:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------Yn8nYNZWR35Us9jgJNEDsk5n" Message-ID: <592d5998-c453-444b-9c02-b71f331b6f9b@gmail.com> Date: Sun, 25 May 2025 18:19:20 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Rick Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings To: Eli Zaretskii References: <86sektz03q.fsf@gnu.org> Content-Language: en-US In-Reply-To: <86sektz03q.fsf@gnu.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 wrote: > Date: Sat, 24 May 2025 16:16:23 -0500 > From: Rick > > 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

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@gnu.org> wrote:
> 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?
--------------Yn8nYNZWR35Us9jgJNEDsk5n-- From debbugs-submit-bounces@debbugs.gnu.org Mon May 26 06:50:19 2025 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 ) id 1uJVPP-0006Ze-8m for submit@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 ) id 1uJVPK-0006WA-5Y for 78582@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 ) 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@gnu.org> From: Eli Zaretskii To: Rick In-Reply-To: <592d5998-c453-444b-9c02-b71f331b6f9b@gmail.com> (message from Rick on Sun, 25 May 2025 18:19:20 -0500) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: <86sektz03q.fsf@gnu.org> <592d5998-c453-444b-9c02-b71f331b6f9b@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon May 26 11:37:03 2025 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 ) id 1uJZss-0006LC-3T for submit@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 ) id 1uJZsp-0006KX-Ez for 78582@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@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@gmail.com> Date: Mon, 26 May 2025 10:36:52 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings To: Eli Zaretskii References: <86sektz03q.fsf@gnu.org> <592d5998-c453-444b-9c02-b71f331b6f9b@gmail.com> <86frgrzlwi.fsf@gnu.org> Content-Language: en-US From: Rick In-Reply-To: <86frgrzlwi.fsf@gnu.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 >> 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. --------------SsUHN29cQE9WeImXgFkUFXhT Content-Type: text/html; charset=UTF-8 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@gmail.com>
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.
--------------SsUHN29cQE9WeImXgFkUFXhT-- From debbugs-submit-bounces@debbugs.gnu.org Mon May 26 12:21:38 2025 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 ) id 1uJaa1-0004I2-Hj for submit@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 ) id 1uJaZz-0004He-QC for 78582@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 ) 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@gnu.org> From: Eli Zaretskii To: Rick In-Reply-To: <7f0afc3e-1e34-4c56-880d-ffad33259f5d@gmail.com> (message from Rick on Mon, 26 May 2025 10:36:52 -0500) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: <86sektz03q.fsf@gnu.org> <592d5998-c453-444b-9c02-b71f331b6f9b@gmail.com> <86frgrzlwi.fsf@gnu.org> <7f0afc3e-1e34-4c56-880d-ffad33259f5d@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 26 May 2025 10:36:52 -0500 > Cc: 78582@debbugs.gnu.org > From: Rick > > 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? From debbugs-submit-bounces@debbugs.gnu.org Mon May 26 13:23:51 2025 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 ) id 1uJbYF-0000WM-9d for submit@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 ) id 1uJbYD-0000W1-LB for 78582@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@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@gmail.com> Date: Mon, 26 May 2025 12:23:42 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings To: Eli Zaretskii References: <86sektz03q.fsf@gnu.org> <592d5998-c453-444b-9c02-b71f331b6f9b@gmail.com> <86frgrzlwi.fsf@gnu.org> <7f0afc3e-1e34-4c56-880d-ffad33259f5d@gmail.com> <861psbz6kr.fsf@gnu.org> Content-Language: en-US From: Rick In-Reply-To: <861psbz6kr.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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@debbugs.gnu.org >> From: Rick >> >> 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? From debbugs-submit-bounces@debbugs.gnu.org Mon May 26 14:33:04 2025 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 ) id 1uJcdA-0005Yf-RA for submit@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 ) id 1uJcd8-0005YG-GP for 78582@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 ) 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@gnu.org> From: Eli Zaretskii To: Rick In-Reply-To: <36d30424-80b0-43c3-b55c-2fdb7dbd1fbd@gmail.com> (message from Rick on Mon, 26 May 2025 12:23:42 -0500) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: <86sektz03q.fsf@gnu.org> <592d5998-c453-444b-9c02-b71f331b6f9b@gmail.com> <86frgrzlwi.fsf@gnu.org> <7f0afc3e-1e34-4c56-880d-ffad33259f5d@gmail.com> <861psbz6kr.fsf@gnu.org> <36d30424-80b0-43c3-b55c-2fdb7dbd1fbd@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 26 May 2025 12:23:42 -0500 > Cc: 78582@debbugs.gnu.org > From: Rick > > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon May 26 20:59:08 2025 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 ) id 1uJiep-0003uV-VL for submit@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 ) id 1uJien-0003tV-7B for submit@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 ) id 1uJieh-0000iO-Id for bug-gnu-emacs@gnu.org; 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 ) 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@gnu.org 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 Date: Tue, 27 May 2025 10:28:36 +0930 X-Gm-Features: AX0GCFuAVW4tvznrVUnqzShLh7m4pgQTk5d_KacztZY172LPbk2x0X7Nv52X8-I Message-ID: Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings To: eliz@gnu.org, bug-gnu-emacs@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::52b; envelope-from=murray.alex@gmail.com; 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-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 07:20:38 2025 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 ) id 1uJsMI-0003hR-AP for submit@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 ) id 1uJsME-0003h0-8x for 78582@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 ) 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@gnu.org> From: Eli Zaretskii To: Alex Murray In-Reply-To: (message from Alex Murray on Tue, 27 May 2025 10:28:36 +0930) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Alex Murray > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 07:40:22 2025 Received: (at 78582) by debbugs.gnu.org; 27 May 2025 11:40:22 +0000 Received: from localhost ([127.0.0.1]:39464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJsfO-00087F-36 for submit@debbugs.gnu.org; Tue, 27 May 2025 07:40:22 -0400 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]:48132) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uJsfK-00080L-Ie for 78582@debbugs.gnu.org; Tue, 27 May 2025 07:40:19 -0400 Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-60179d8e65fso5689468a12.0 for <78582@debbugs.gnu.org>; Tue, 27 May 2025 04:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748346011; x=1748950811; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YbzAIs+daSOVfAWeWMdsjJ6RAKctGqKm5m7cPVw8K14=; b=OZV4VzEur5xEvoiEMbbWdRwXniwj+fWxtUd+9tXmblkWzqF4qcWm/xTrLQHSpAu51P gLu7qpwBsDmhzmedCHLURdlSEzMJwrAxzvOAa5uaUQ8at8BiLyNIjztdqa+N9Yvi4qOW oIYZ101/tksgBJvj51yHVI64zpuktIVIGn8Q5eYA8wfpVhFKy984fZPdWvr5ue298G8m MhtPVp0wZXSWPrDjWU5440ZO4oHfw5jFIUXnfmVxMvAuWgzayOA/1V7++saAQ8/yEhqO iTeqWyHntBU6kry6WlSPCggzLAAiW+BaBW//Jxce45wB/7FjSQZ/bY25dPGKh43PnWUp wDag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748346011; x=1748950811; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YbzAIs+daSOVfAWeWMdsjJ6RAKctGqKm5m7cPVw8K14=; b=AuuiB60YA3XYtv/zAPqo+xSLw3wn2PP0gh1giXLMyvVLNXR/UjOryY2RQN1EOZjT4x 9SWRbCmGjMKwjkZaGv2cnFm+SIoZp0lpotDDXq6lSujogiwgTAYBTKQ+rCEV6pO9g7bh 2KKD6IItFr8aNSt0FfhZP2EuHs9eK2KIMOsRIc/Qg5ypvDW+w6Mc4Vr58cn8lEejfaFu YHPfVo2YozsfhuUL6oFtalwzTxTKIGmomcd9H6GKYZP8T4rHw78vFKNKIUTP0j85aBOG t7zpHPYwRvTRQUSequFMS+9ladpPs/cuWbZbMwcs+rf4R98pBJ9hbES8GqEPVFcI4DoH aRwA== X-Gm-Message-State: AOJu0YzDf3J9cvh5x0tjFkG5AWElKBvoqVhCiSCDjbzuZEfCa8j94X9q YJtR6Nwa+rlLlXH9zX3dTvJOYuU+D/OtazliiQPLLtlpJWZKn2RrHs4m3bky7DM1dUF4B/sPhb5 d/l0A+TGJfAyMkPvFBqoxXp5ip4gfHor7FZm5 X-Gm-Gg: ASbGncuz9AMlhR91RQREMAn9hQeZW5ylmELiGQPG52IRurwl688FDgdB1zbGCZss77f D+a6eodXnDA8g5+Gz4eM5fwEdqfS7gKHd5n82B3OMkHRGuE2zG7NoF7cHFPKLUQ0tL2vSlmGMIx 8HWC8r3R9WkvC8nO53nsxp7/J6vt6ge0LeaCVPh52I/FOTfWqt6ES29lERBJ/otkc= X-Google-Smtp-Source: AGHT+IGC5Hv4Pic4U6aQWQC020RcqoR2hc1SParHNwRmWT0VY80zJu5H0sGNr7oSgbOyaDlD80YL/vPapZaMiBmBwBk= X-Received: by 2002:a05:6402:40cc:b0:5fa:8277:3d5c with SMTP id 4fb4d7f45d1cf-602db4affb3mr9992999a12.30.1748346010961; Tue, 27 May 2025 04:40:10 -0700 (PDT) MIME-Version: 1.0 References: <86jz62xpu0.fsf@gnu.org> In-Reply-To: <86jz62xpu0.fsf@gnu.org> From: Alex Murray Date: Tue, 27 May 2025 21:09:54 +0930 X-Gm-Features: AX0GCFsRxQ63Hh-wMYxOy_C_4K7JAmeOYoL_fwcTJaHoYWo7VPvaGPZdJWybs-s Message-ID: Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Eli, On Tue, 27 May 2025 at 20:50, Eli Zaretskii wrote: > > > 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? > The stable channel of the emacs snap builds from the 30.1 release tarbal l- https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L64 > 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. Your hint about toolkit got me interested - for a bit more info on the emacs snap, I build emacs both with pgtk (https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L296) and without it (https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L314) and then bundle both inside the snap and use a script to try and choose the most appropriate one to use at runtime. If I force it to use the gtk variant (ie. non-pgtk) then I can no longer reproduce this issue with the emacs snap. However I am able to reproduce it with the pgtk variant. Could it be an issue with pgtk specifically and not the emacs snap perse? Thanks, Alex From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 08:07:57 2025 Received: (at 78582) by debbugs.gnu.org; 27 May 2025 12:07:57 +0000 Received: from localhost ([127.0.0.1]:39694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJt64-0001eR-J5 for submit@debbugs.gnu.org; Tue, 27 May 2025 08:07:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50464) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uJt60-0001dj-Qp for 78582@debbugs.gnu.org; Tue, 27 May 2025 08:07:54 -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 ) id 1uJt5u-0006Ea-P2; Tue, 27 May 2025 08:07:46 -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=Mi4NBF+YQBW4wyCNDAMUMX8kbFKuBiP/9n9La2/bN5M=; b=gAOIElqAXiAd wGyB5F0gnky1iHy6e3lrPhisPo/lUXIPhMTA76psDzkIhb5I72LWqpBcgE/tk7RkksuhXcgxwL6n9 NnH5kMRYvMx80cjEsJ5tNAHx8zT1zfKZdv59YOt5zeteeT2eCW7cUxnPT4ULXZ1q2MarrdbkOR+uO 5V74h4Pya1L/qlFTh+3miRHHvWWWrKT9UydTv1qGOjF596B4tOWdctR89bZhM+iRUwIrYn7IqXO4v 11nQMpy/EdpWB92rBKaLk04REugqvuQbspg3QzkTUkeGcV+/ATSjKvV4VyQpgLUyQ4i77sm3YO9YE FTWBkw4K1Bw96iVSpPItlw==; Date: Tue, 27 May 2025 15:07:37 +0300 Message-Id: <86cybuxnna.fsf@gnu.org> From: Eli Zaretskii To: Alex Murray , Po Lu In-Reply-To: (message from Alex Murray on Tue, 27 May 2025 21:09:54 +0930) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: <86jz62xpu0.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Alex Murray > Date: Tue, 27 May 2025 21:09:54 +0930 > Cc: 78582@debbugs.gnu.org > > Your hint about toolkit got me interested - for a bit more info on the > emacs snap, I build emacs both with pgtk > (https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L296) > and without it (https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L314) > and then bundle both inside the snap and use a script to try and > choose the most appropriate one to use at runtime. > > If I force it to use the gtk variant (ie. non-pgtk) then I can no > longer reproduce this issue with the emacs snap. However I am able to > reproduce it with the pgtk variant. > > Could it be an issue with pgtk specifically and not the emacs snap perse? Could be. Would people who use PGTK please try reproducing the issue with the recipe and report? Po Lu, any ideas why the PGTK build could show this strange behavior? From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 01 23:49:30 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 03:49:30 +0000 Received: from localhost ([127.0.0.1]:45217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLwAz-0004Ww-IM for submit@debbugs.gnu.org; Sun, 01 Jun 2025 23:49:30 -0400 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]:45304) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uLwAw-0004WA-7z for 78582@debbugs.gnu.org; Sun, 01 Jun 2025 23:49:27 -0400 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5533302b49bso5160825e87.2 for <78582@debbugs.gnu.org>; Sun, 01 Jun 2025 20:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748836159; x=1749440959; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=3z1h1PRQNyNXrgJ9Ds98VNJoW55iFsvyTMjdXSK0uC8=; b=Q18xEmHtAm9DK4xJfa2PdWad2dj5QT8aJ22X/TEuA08TPE2sXUimy7D6vev3o2l3Ft FvRjaUUl6CJtlcwlNogd0qjA2zPfUmZVG4FuOvyJjahWOjrBE4/5lZawADKFAV3sOE/v bR95eP3qriuIjRJ4tFJ78cHIV30KW8Fxtl0/BWttBHykqwx4S/4918EySFx1i7vi7/H0 XXsYQzzA2Uvj/Xg76w5wCAIZq9FLj8PPyjdrhzUdd0US/8iaa+QkMEGsqnF0GYFRkvZJ RcfOyR0pDlNLsRqz3ARsTrt7GlEfDwm4Zr1CyU5Bx8zKBJ42RCQljUMyp3TqsZhi2iyN FMfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748836159; x=1749440959; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3z1h1PRQNyNXrgJ9Ds98VNJoW55iFsvyTMjdXSK0uC8=; b=R2ZzP76HDS1tvXcmvTCyRdAzJmnyf+obOpscYEWjy3tD+SYk5RP3OyhVgJfGDu04dn OrRAzRrgRQXsT9VXoabitahzLfDYPHDThekTMPT4mn2D2jiUNFtgq8nWj5jiDVXtJRhY TMIsGuKoleO/olHT8F/i29GvLNBcE6bqVZOJNnneqX9AuuHmv42Nu4ji+ROpgMBFeMaR xqCxd4/8Oci+TzrDYhfD73P9rkliVqInNQH0dGIJTyHipEUOkGxV/5/IxqQ6Zz9MtoSg GJzlxC8yzl7GsN2HOfht4M+flLK2rfuq9s8fFcXC+RjkWdmQwA4GZ5Lrehd00CdcbkMq AoDw== X-Forwarded-Encrypted: i=1; AJvYcCWP2QdsZH7Rw4YuXdCoQ2u/m1BX8oGfDus6SBFgu/bKNAZcDkckZMSuICNEBXzfDi75fU/Mjw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwFaxQdONSblQXV3B8Nyal+ijD7uNtP8lvDA47UxSxom6jzljqt 6Rrc2zTLjoo2fV/njmsFO+DSpUJ3sjWx123tKCwysBp7MLbK1vioWA4NZYTZ+awL X-Gm-Gg: ASbGncuXkR8FKN5dWUBEhGd9Geux8cpUrPo14RJAXIO1Y9gUHlXFcZKm9hYTmuLAiDd FoAeycnwngP1Ix6Eoyhqz5t9Yj5YgE5ydQh8Ve/BIFaECdiJAWayvV1J2E0NK7SKb/DyIih/a/E BUQte2HWzeiXI54hAsCikdJVALl61IEPEPBHMK7vYwv9gZ/JF0hrJrmFyCYzBwHIzNrvU9vUYQ1 goXH/Zm0yAMC8ckFB5lDpP1TpoNeScATbxJV+O6xhlEx59UdvCWiEH6K91RCmz2v7y4xHlSsgPt 2E6RxJCEipsSMVu6RrD1cKaDY+uukjZ23LOaaJnOR12EJR+ILT75KoFPaCkDTUBccab3Pyhlwma +EuDDmEsXLS8s8n2iojJLOmJ8xiZ7P3fLpX3fhPPsWsXyNkICTMZ+vWnHI010 X-Google-Smtp-Source: AGHT+IEUWSG378XjPa9CoM/+dzMNBCkNB+P/hWoF9h0ujyhzJdVR9l51E6o+MuDYdAvb33u9pOKhzQ== X-Received: by 2002:a05:6512:23a7:b0:553:2517:fe0d with SMTP id 2adb3069b0e04-5533b8e12f4mr3601823e87.10.1748836158767; Sun, 01 Jun 2025 20:49:18 -0700 (PDT) Received: from pro2 (p200300e0b72e350060f297ff9ecb4644.dip0.t-ipconnect.de. [2003:e0:b72e:3500:60f2:97ff:9ecb:4644]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-55337910329sm1469356e87.141.2025.06.01.20.49.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Jun 2025 20:49:17 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: <86cybuxnna.fsf@gnu.org> References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> Date: Mon, 02 Jun 2025 05:49:14 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: Alex Murray , Po Lu , 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Alex Murray >> Date: Tue, 27 May 2025 21:09:54 +0930 >> Cc: 78582@debbugs.gnu.org >>=20 >> Your hint about toolkit got me interested - for a bit more info on the >> emacs snap, I build emacs both with pgtk >> (https://github.com/alexmurray/emacs-snap/blob/master/snapcraft.yaml#L29= 6) >> and without it (https://github.com/alexmurray/emacs-snap/blob/master/sna= pcraft.yaml#L314) >> and then bundle both inside the snap and use a script to try and >> choose the most appropriate one to use at runtime. >>=20 >> If I force it to use the gtk variant (ie. non-pgtk) then I can no >> longer reproduce this issue with the emacs snap. However I am able to >> reproduce it with the pgtk variant. >>=20 >> Could it be an issue with pgtk specifically and not the emacs snap perse? > > Could be. Would people who use PGTK please try reproducing the issue > with the recipe and report? > > Po Lu, any ideas why the PGTK build could show this strange behavior? I encountered this on macOS today. Reproducer with an installed Emacs=20 (which is the Emacs.app on macOS): ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q In *scratch*, eval (global-set-key [f4] #'kill-current-buffer) (documentation 'rectangle-mark-mode) Then C-h k and observe that it has been redefined. A backtrace how this happens with which-key is at then end. In short, which-key calls 'documentation' which loads lisp/loaddefs which evaluates the global-set-keys loaddefs.el contains. I have no idea how to fix this. global-set-key("\30(" kmacro-start-macro) byte-code("\300\301\302\303\304$\210\305\302\306\"\210\307\310\311\"\210\= 307\312\313\"\210\307\314\315\"\210\307\316\317\"\210\307\320\321\"\210\307= \322\323\"\210\300\323\324\325\304\326%\210\327\330\331\332#\210\333\330\33= 1\334#\210\300\311\324\335\304$\210\300\313\324\336\304$\210\300\337\324\34= 0\304$\210\300\317\324\341\304$\210\300\321\324\342\304$\210\300\315\324\34= 3\304$\210\300\344\324\345\304$\210\300\346\324\347#\210\300\350\324\351#\2= 10\333\350\346\334#\210\300\352\324\353\304$\210\327\354\355\"\210\300\355\= 324\356\304$\210\305\324\357\"\207" [autoload kkc-region "kkc" ("/Users/ger= d/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 768162) t regis= ter-definition-prefixes ("kkc-") global-set-key "\30(" kmacro-start-macro "= \30)" kmacro-end-macro "\30e" kmacro-end-and-call-macro [f3] kmacro-start-m= acro-or-insert-counter [f4] kmacro-end-or-call-macro "\30\13" kmacro-keymap= "kmacro" ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.= elc" . 768555) keymap defalias kmacro-exec-ring-item funcall "Execute item = ITEM from the macro ring.\nARG is the number of times to execute the item."= make-obsolete "29.1" ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/li= sp/loaddefs.elc" . 768689) ("/Users/gerd/Desktop/Emacs.app/Contents/Resourc= es/lisp/loaddefs.elc" . 769692) kmacro-call-macro ("/Users/gerd/Desktop/Ema= cs.app/Contents/Resources/lisp/loaddefs.elc" . 770110) ("/Users/gerd/Deskto= p/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 770706) ("/Users/gerd/D= esktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 771651) ("/Users/g= erd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 771871) kmacr= o-end-call-mouse ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/lo= addefs.elc" . 772193) kmacro ("/Users/gerd/Desktop/Emacs.app/Contents/Resou= rces/lisp/loaddefs.elc" . 772352) kmacro-lambda-form ("/Users/gerd/Desktop/= Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 772507) kmacro-name-last-= macro ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc"= . 772549) kmacro-menu list-keyboard-macros ("/Users/gerd/Desktop/Emacs.app= /Contents/Resources/lisp/loaddefs.elc" . 772804) ("kmacro-")] 6) documentation(rectangle-mark-mode) which-key--propertize-description("rectangle-mark-mode" nil nil nil "rect= angle-mark-mode") which-key--format-and-replace((("C-x DEL" . "backward-kill-sentence") ("C= -x ESC ESC" . "repeat-complex-command") ("C-x RET" . "prefix") ("C-x SPC" .= "rectangle-mark-mode") ("C-x TAB" . "indent-rigidly") ("C-x #" . "server-e= dit") ("C-x $" . "set-selective-display") ("C-x '" . "expand-abbrev") ("C-x= (" . "kmacro-start-macro") ("C-x )" . "kmacro-end-macro") ("C-x *" . "calc= -dispatch") ("C-x +" . "balance-windows") ("C-x -" . "shrink-window-if-larg= er-than-buffer") ("C-x ." . "set-fill-prefix") ("C-x 0" . "delete-window") = ("C-x 1" . "delete-other-windows") ("C-x 2" . "split-window-below") ("C-x 3= " . "split-window-right") ("C-x 4" . "ctl-x-4-prefix") ("C-x 5" . "ctl-x-5-= prefix") ("C-x 8" . "prefix") ("C-x ;" . "comment-set-column") ("C-x <" . "= scroll-left") ("C-x =3D" . "what-cursor-position") ("C-x >" . "scroll-right= ") ("C-x X" . "prefix") ("C-x [" . "backward-page") ("C-x \\" . "activate-t= ransient-input-method") ("C-x ]" . "forward-page") ("C-x ^" . "enlarge-wind= ow") ("C-x `" . "next-error") ("C-x a" . "prefix") ("C-x b" . "consult-buff= er") ("C-x d" . "dired") ("C-x e" . "kmacro-end-and-call-macro") ("C-x f" .= "set-fill-column") ("C-x g" . "magit-status-quick") ("C-x h" . "mark-whole= -buffer") ("C-x i" . "insert-file") ("C-x k" . "kill-buffer") ("C-x l" . "c= ount-lines-page") ("C-x m" . "compose-mail") ("C-x n" . "prefix") ("C-x o" = . "other-window") ("C-x p" . "prefix") ("C-x q" . "kbd-macro-query") ("C-x = r" . "prefix") ("C-x s" . "save-some-buffers") ("C-x t" . "prefix") ("C-x u= " . "vundo") ...) nil) which-key--get-bindings([24] nil nil) which-key--create-buffer-and-show([24]) which-key--update() apply(which-key--update nil) timer-event-handler([t 0 1 0 t which-key--update nil idle 0 nil]) From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 01:42:14 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 05:42:14 +0000 Received: from localhost ([127.0.0.1]:46083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLxw6-0004UM-1q for submit@debbugs.gnu.org; Mon, 02 Jun 2025 01:42:14 -0400 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]:44264) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uLwik-00077Z-GE for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 00:24:23 -0400 Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-3a375e72473so2233541f8f.0 for <78582@debbugs.gnu.org>; Sun, 01 Jun 2025 21:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748838254; x=1749443054; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=V4/oo7N2q/wjnpvxQH3SLd1NZ+RFiMTuDpahkSDD5Fk=; b=kCC911DPgmztObykFJY7f/RKZtWVwfiUuwv9h6XKmQ7qO7whbdHfDbyoh87qB3Z9NS nBpYNXHAcVfbSG+gQveBUYTLUryImuMDTiUvL9XP+rbX1F6cXNyH576ny3vMOHU3OgaK 4ldUpqGfD7JYiwFZIWS0CQ8B3Ld4LDGHTgckRg3QK6bx25Et0Cd9ZRpr9Zxd62pQEPQ1 ZAU7VuDIpqdjAQdihiluOLwRUebS4G/hzwQc3xLc3mXv710JzkPTN+IImAiWptOaaT70 N8GRyBDaySKWhxM5+2IqqA2nngV68/eMhvSn2ntpAaaJbj+WUUoS3Q3xgZfsRcKn2Ilt EEKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748838254; x=1749443054; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=V4/oo7N2q/wjnpvxQH3SLd1NZ+RFiMTuDpahkSDD5Fk=; b=FHnA1MdUnoTUyWbpAkobMEhsnhlC9NnR1CoalIgWM+/XmedXGiVyGS7VdMXud+teuI XuNmBLB4JsOx53UHCENVcBsxfJ6UmYLLnw21iUY6JcvqtVxHU5/DueQDlmT0pJfumEeb TqunDwkwuh/UvXrvpL2ZsDyNnWHozzxQgERDzWSpv5rKGu0ZZgMYbMNgiuVJkhYKVmtB MMPS4eYQopPw4tESo9y2kD8udUC5Y/iaWSPcYRhYNNkLVY+fJz8aXm+302RC2duSvfB6 AwDedSuFW91AJh+eDBz/WFg61FCH8/edhhXPTXOaw1kmV2BqJvitT8WiwIZf4O5IHXP1 HNiw== X-Forwarded-Encrypted: i=1; AJvYcCXmZPUke49zLy2t5G4gX+co69O+7mERA37AFDH31Duv8HY0oPAR2rXulmyeJSnjIHZqag2Vsw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxr/pZToDgTt08UtaAoEVW0IH5+gTcEuvnTNiuhIHVAmGBtq+Xq NMmFsqG49CnrlhbH2rtoqziULzT0XQPtTgKuJqZ1lmG1FI4rImx87ZNzY5n1NmFg X-Gm-Gg: ASbGncuNoPXtdRANwBOPmz+8KHWhjCupB78uQGXIl+Lc/4UKCYlqBn5bPjIr28bXxml OQFKBS/Du952qIqoE3k6tBhB1lwsUmD02Kr0HDIoJpf7+jpNOkOL1MyFpm6CT6dmaWfCjDVJRYL lCK0dRa+Oy3/LAfJNCll1t95FywTph4NX5yCg/ggFt4+8gLj//CHqXBz9Us92DFCtEe+UuYyiCy 9yWo9mqepJIoNxrOtrMxvcfXl50v9fefSasluIeijISrH4z+o9L3rOsImowgQmUdKMIlWzEoAu3 x4BWR4F8q0MFwirdS8XzkNLfqKm6HoLtu523C/z7VrxogauKHkq4mp/A7wmsyRRZ0rmM+vdUq1+ bDm1EGB3xRc8m+FhfWJgprAtod6Y59m4F9y3WkbI1EW89nj6kc7Iz153XGik1 X-Google-Smtp-Source: AGHT+IFZQAhXPpn4GpXA0opB+/8YGisocc9rJ16Sg7C+AuwGCO5UorJ2Bc6p+yi//fkhszRWVKVxVg== X-Received: by 2002:a05:6000:220b:b0:3a3:7077:ab99 with SMTP id ffacd0b85a97d-3a4f7a6d2a4mr9167202f8f.45.1748838253746; Sun, 01 Jun 2025 21:24:13 -0700 (PDT) Received: from pro2 (p200300e0b72e350060f297ff9ecb4644.dip0.t-ipconnect.de. [2003:e0:b72e:3500:60f2:97ff:9ecb:4644]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe6c7e5sm13310722f8f.28.2025.06.01.21.24.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Jun 2025 21:24:13 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> Date: Mon, 02 Jun 2025 06:24:12 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: Alex Murray , Po Lu , 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > I have no idea how to fix this. In any case, code that changes global state like global-set-key does looks wrong in loaddefs.el. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 03:26:27 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 07:26:27 +0000 Received: from localhost ([127.0.0.1]:47067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLzYw-0003tI-V6 for submit@debbugs.gnu.org; Mon, 02 Jun 2025 03:26:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43966) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLzYt-0003sj-8R for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 03:26:25 -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 ) id 1uLzYm-0003Yz-5U; Mon, 02 Jun 2025 03:26:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=65fItdBgBJ9VcaWBqCbwdwsRAaOuxvIaMev0pjazZAU=; b=bC5zTW+RZcNpPLhmdU5O /ZcX0/o+GWflGnGHpZdJL40uQ6SDI8UVAlkyp0w2W7Smd/uwY8SSsKmqdxLLVhC0m2Ppy9JawsiqZ yiW0ku9A/jGy88Jpfox1DGwYYU/QLnsTwG/d843uSwltCl3zc7sNJx9xByWahXIpyyExWHzFWavDE hNkswUmMASDxfBWu7pbSkH11m/rZTsgt5ZCNT2MsdLIoY2rz32WyWsdWvYP9+2uHjSJNqfw0USZq9 8vPduXwhWspfTv96C8CgMKEoLDk2nN/3NeF0NwyRDDqI+wvthLurT7ENHHkpX2IU/0bWDV8Zqflg0 4qu6HEza8KnjiQ==; Date: Mon, 02 Jun 2025 10:26:12 +0300 Message-Id: <86msaqppt7.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= , Stefan Monnier In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Mon, 02 Jun 2025 05:49:14 +0200) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: Alex Murray , Po Lu , > 78582@debbugs.gnu.org > Date: Mon, 02 Jun 2025 05:49:14 +0200 > > Eli Zaretskii writes: > > > Po Lu, any ideas why the PGTK build could show this strange behavior? > > I encountered this on macOS today. Reproducer with an installed Emacs > (which is the Emacs.app on macOS): > > ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q > > In *scratch*, eval > > (global-set-key [f4] #'kill-current-buffer) > (documentation 'rectangle-mark-mode) > > Then C-h k and observe that it has been redefined. Not reproducible on my system with today's master branch. When I press "C-h k " after evaluating the above line by line, I get the expected documentation of kill-current-buffer. > A backtrace how this happens with which-key is at then end. In short, > which-key calls 'documentation' which loads lisp/loaddefs which > evaluates the global-set-keys loaddefs.el contains. "M-x debug-on-entry RET global-set-key RET" doesn't pop up the debugger when I evaluate "(documentation 'rectangle-mark-mode)". Anyway, why would Emacs want to load loaddefs, when loaddefs is preloaded? > I have no idea how to fix this. And I have no idea why this happens on some systems, but not on others. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 03:33:30 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 07:33:31 +0000 Received: from localhost ([127.0.0.1]:47170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLzfm-0004OM-Ia for submit@debbugs.gnu.org; Mon, 02 Jun 2025 03:33:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55284) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uLzfj-0004No-HO for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 03:33:27 -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 ) id 1uLzfd-0004N0-UO; Mon, 02 Jun 2025 03:33:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Qhs8JJj+dsS2cavW5J8QIy3hglCDYQ6Gu22tQ1ks15Y=; b=IpEPng3Zf/kd2EiO20Hk Goh81ByqVmF/sKAGCtjLf5nuy5SMERUGgnrUeBJww5DPZe72rTyRY6dbCURpb7p8p+f6pxgQ2yC86 5ZeYyRB7w/gHMMOdr9I1X2EWXRVuzUJcKjcvHyxr85Xrr5lIcGfYVZOgbwyYn90LLFDBTOPm+6Lrq ITSVRrAfwn7jiSmdRonp0yA6dhunmLQyPHNCYelTDIqsgmKQW/ffQf5xvw0exEmvNRFjVfUN3Gx96 ykAyT+KjUiH2tZa/5lX3ZWTkm/eLBob2MnqYVz6WkRDlnDzNFEvsTfXmK/sak62s8ElaQYHAKcSol Ml9kDAdu4DjE5g==; Date: Mon, 02 Jun 2025 10:33:18 +0300 Message-Id: <86ldqapphd.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= , Stefan Monnier In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Mon, 02 Jun 2025 06:24:12 +0200) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: Alex Murray , Po Lu , > 78582@debbugs.gnu.org > Date: Mon, 02 Jun 2025 06:24:12 +0200 > > Gerd Möllmann writes: > > > I have no idea how to fix this. > > In any case, code that changes global state like global-set-key does > looks wrong in loaddefs.el. What's wrong with it? It's a direct effect of this part of kmacro.el: ;;; Provide some binding for startup: ;;;###autoload (global-set-key "\C-x(" #'kmacro-start-macro) ;;;###autoload (global-set-key "\C-x)" #'kmacro-end-macro) ;;;###autoload (global-set-key "\C-xe" #'kmacro-end-and-call-macro) ;;;###autoload (global-set-key [f3] #'kmacro-start-macro-or-insert-counter) ;;;###autoload (global-set-key [f4] #'kmacro-end-or-call-macro) ;;;###autoload (global-set-key "\C-x\C-k" #'kmacro-keymap) ;;;###autoload (autoload 'kmacro-keymap "kmacro" "Keymap for keyboard macro commands." t 'keymap) IOW, we do this on purpose, for the reasons explained in the comment. Given that loaddefs is supposed toe be loaded just once, during dumping, why is that wrong? From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 03:42:28 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 07:42:28 +0000 Received: from localhost ([127.0.0.1]:47261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uLzoS-00053s-6B for submit@debbugs.gnu.org; Mon, 02 Jun 2025 03:42:28 -0400 Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]:49333) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uLzoP-00053V-Pg for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 03:42:26 -0400 Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-3a3673e12c4so2670577f8f.2 for <78582@debbugs.gnu.org>; Mon, 02 Jun 2025 00:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748850139; x=1749454939; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=WSdE7cyafpA2n55NRDfV019IYwB9lb8m5JFpITN2hzo=; b=AweX+ZjcOE5+8fUbjxeDNqo7USEbiz3Urtx/rf2/x0a+4QLyS+IpSj8w86bRMcia9m bmrMnF1FUKPDlJXH/uNvm1QKaRdZOtfsfldmV3034773fnj0MKDMp/OTIGUiH98xR6Hu XaDCviI/BzQWuMuZTAgHzwO9nx1SnI9W9EKz3NJ/NFrMdRRjrw8z5ULEaVy2XW937/IT omy61nSUGqJuLwtcWJ32CAa34+fY4E80YTJNOYu9nmtM+yGr96KSpa7taO6/ogEjTKbi Bk3OaIc61V+jQY/NHB6HYaGsrdDHFSiv2C01kqbTBIiP9cc0TjqDAAOQv1qlockje4Hp PyRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748850139; x=1749454939; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=WSdE7cyafpA2n55NRDfV019IYwB9lb8m5JFpITN2hzo=; b=jRr6XYeNQEA8Mq94/FoOssCpamUcRUoaRF9yIag7y2KcmDqANyLUauaIlqc3rJx1j3 x4ZTALSDUQjt4HYgPLsOJaGy9IaICZB1ZCJaR7u7orzTo/IBt1iDXOv4mbD2t28NzBGw joMYXXeBZUZSurgQ407HgjbRtXm20/M35vZgNy7OiTJVIyw2wLf6Bpg37egqPpMxLBZQ 13GyMZN1IfKNsC73EDCyhIFZwSKKiLNq3HW/gWxYKNymtXMghbS+BDE16Hjb/STXR8Gw MTSyGd0T7/6KoKOQdmHB1WFx//Ilb6dRja0eHzt05qbKKPZaAQJnNTKbXfQI0XbeHP5J 6dyQ== X-Forwarded-Encrypted: i=1; AJvYcCWv6fEGqKg8/pywzKpWa8P+QGVsxkophazp3VU6T10mx4CR6Wy0/XvErAxCzj67PBe4ZghROg==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxoc2ZyiWq3cqXXh525RukG029inTSqkCaL9MucMQHPm6HQUjVt 0wAk8J1qgDi7XSxuAIqpXmrWGEQuqFIYtXRRKWG3sUvCvuiE1uZqMFFKDmH9ESG5 X-Gm-Gg: ASbGncubzDvR6AEH3cZhoCsaFsU50i18uSdokBwPfaeIgy7hYDiZaLRfgVK6KmCxSVa VmROiwCbmOz4g+xhieneH7iYulXINSDWigqXBoL3Gyv0MobNxkeVNUf4X6mxGdb/qWfFR6erCn2 L89rodZJQRxBAXKwmPZjb0+Oojb59bMIBYh/rdg/riQoQ3aiflB0I24SI/UWRyETUG/APEs4eri J2bwjKtvxorMs5SSozLNMiDHWuBlooHle6YqGjFCukXGoVu+XsKCgvkUmLgCFtpIQp7zs+Gpxsz vyyzNeSIkeeJnIUBNsUFXp7pc/XOSjYLC0aDGWZfoODgmmPxbgu0UJWyXg+9kHkZguE5Z7KNh9R UJ1UbXTKX8xdxj2j//KU5VJgfr4y4o04nEr+uBrdTSyK16kEDpj4X8I/XICqo X-Google-Smtp-Source: AGHT+IF1NIKu3KmRnMEUoelbMCREo14ee5p5fUcIz4SJcf8FI1eWd5j9kCl+/D0fvoQZGtyor/VzrQ== X-Received: by 2002:a05:6000:4282:b0:3a4:e8c4:7a78 with SMTP id ffacd0b85a97d-3a4f7aafd2bmr8862956f8f.52.1748850139012; Mon, 02 Jun 2025 00:42:19 -0700 (PDT) Received: from pro2 (p200300e0b72e350060f297ff9ecb4644.dip0.t-ipconnect.de. [2003:e0:b72e:3500:60f2:97ff:9ecb:4644]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-450d7fc281csm114282425e9.40.2025.06.02.00.42.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 00:42:18 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: <86msaqppt7.fsf@gnu.org> References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86msaqppt7.fsf@gnu.org> Date: Mon, 02 Jun 2025 09:42:17 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, Stefan Monnier , 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: Alex Murray , Po Lu , >> 78582@debbugs.gnu.org >> Date: Mon, 02 Jun 2025 05:49:14 +0200 >>=20 >> Eli Zaretskii writes: >>=20 >> > Po Lu, any ideas why the PGTK build could show this strange behavior? >>=20 >> I encountered this on macOS today. Reproducer with an installed Emacs=20 >> (which is the Emacs.app on macOS): >>=20 >> ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q >>=20 >> In *scratch*, eval >>=20 >> (global-set-key [f4] #'kill-current-buffer) >> (documentation 'rectangle-mark-mode) >>=20 >> Then C-h k and observe that it has been redefined. > > Not reproducible on my system with today's master branch. When I > press "C-h k " after evaluating the above line by line, I get the > expected documentation of kill-current-buffer. It seems to depend on trying this in an installed Emacs, and that that Emacs is older than what is built in the repo that I built it in. For example, the Emacs I'm running is from some weeks ago when I started using the NS freeze workaround I posted to emacs-devel. In the repo, a more current Emacs is built. >> A backtrace how this happens with which-key is at then end. In short, >> which-key calls 'documentation' which loads lisp/loaddefs which >> evaluates the global-set-keys loaddefs.el contains. > > "M-x debug-on-entry RET global-set-key RET" doesn't pop up the > debugger when I evaluate "(documentation 'rectangle-mark-mode)". > > Anyway, why would Emacs want to load loaddefs, when loaddefs is > preloaded? Could be Fdocumentation: doc.c: 365 if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc)))) 366 { 367 Lisp_Object tem =3D get_doc_string (doc, 0); 368 if (NILP (tem) && try_reload) 369 { 370 /* The file is newer, we need to reset the pointers. */ 371 reread_doc_file (Fcar_safe (doc)); 372 try_reload =3D false; doc.c: 310 static void 311 reread_doc_file (Lisp_Object file) 312 { 313 if (NILP (file)) 314 Fsnarf_documentation (Vdoc_file_name); 315 else 316 save_match_data_load (file, Qt, Qt, Qt, Qnil); 317 } That's of course not the root cause, but somehow it's happening. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 03:54:52 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 07:54:52 +0000 Received: from localhost ([127.0.0.1]:47391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM00S-0005wy-8Y for submit@debbugs.gnu.org; Mon, 02 Jun 2025 03:54:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46790) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uM00Q-0005wj-EV for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 03:54:51 -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 ) id 1uM00J-0006jN-Ek; Mon, 02 Jun 2025 03:54:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=8skeBxSR0R3pgbarivVHGfOMB9NX7swBEp2vkbfJpK4=; b=e6NvetOYhK2PTQuPH/uh odSWHsCvdoH0m7ir5/AANcRdJ4nNffb4m8w+gNHTny9MZSh3lfmVmrzzC/aqYEQ+chNgjWz6zf9V9 s+OgimD78QgKQHOXF/LYZC8w/BMsf2RMdyrbjhbSh0nGDPbdqID9n62axkMCWfFPaLXp0IoDfDusP PQeZ0PPeibM5OL0nV65hNorH1mM4FPVE87aXMvFkLR4sJjZ9Wr01P3z/CBJOonyOswja67r3oFBGM +JlP0eTrZCtysyJK2Gpmf+rrZUFgVKShSt1aak5+L3FHo76HegtIBZiq0ESBNx5+wzPggJVg9J/Z0 FoyX/6vsHn8UzA==; Date: Mon, 02 Jun 2025 10:54:35 +0300 Message-Id: <86ecw2pohw.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Mon, 02 Jun 2025 09:42:17 +0200) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86msaqppt7.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: Stefan Monnier , murray.alex@gmail.com, > luangruo@yahoo.com, 78582@debbugs.gnu.org > Date: Mon, 02 Jun 2025 09:42:17 +0200 > > Eli Zaretskii writes: > > >> From: Gerd Möllmann > >> Cc: Alex Murray , Po Lu , > >> 78582@debbugs.gnu.org > >> Date: Mon, 02 Jun 2025 05:49:14 +0200 > >> > >> Eli Zaretskii writes: > >> > >> > Po Lu, any ideas why the PGTK build could show this strange behavior? > >> > >> I encountered this on macOS today. Reproducer with an installed Emacs > >> (which is the Emacs.app on macOS): > >> > >> ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q > >> > >> In *scratch*, eval > >> > >> (global-set-key [f4] #'kill-current-buffer) > >> (documentation 'rectangle-mark-mode) > >> > >> Then C-h k and observe that it has been redefined. > > > > Not reproducible on my system with today's master branch. When I > > press "C-h k " after evaluating the above line by line, I get the > > expected documentation of kill-current-buffer. > > It seems to depend on trying this in an installed Emacs, and that that > Emacs is older than what is built in the repo that I built it in. For > example, the Emacs I'm running is from some weeks ago when I started > using the NS freeze workaround I posted to emacs-devel. In the repo, a > more current Emacs is built. > > >> A backtrace how this happens with which-key is at then end. In short, > >> which-key calls 'documentation' which loads lisp/loaddefs which > >> evaluates the global-set-keys loaddefs.el contains. > > > > "M-x debug-on-entry RET global-set-key RET" doesn't pop up the > > debugger when I evaluate "(documentation 'rectangle-mark-mode)". > > > > Anyway, why would Emacs want to load loaddefs, when loaddefs is > > preloaded? > > Could be Fdocumentation: > > doc.c: > 365 if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc)))) > 366 { > 367 Lisp_Object tem = get_doc_string (doc, 0); > 368 if (NILP (tem) && try_reload) > 369 { > 370 /* The file is newer, we need to reset the pointers. */ > 371 reread_doc_file (Fcar_safe (doc)); > 372 try_reload = false; > > > doc.c: > 310 static void > 311 reread_doc_file (Lisp_Object file) > 312 { > 313 if (NILP (file)) > 314 Fsnarf_documentation (Vdoc_file_name); > 315 else > 316 save_match_data_load (file, Qt, Qt, Qt, Qnil); > 317 } > > That's of course not the root cause, but somehow it's happening. So you are saying that the problem happens if Emacs is older than its loaddefs.el? If so, this is not a situation we support, so I think this bug is not a bug at all. When loaddefs is regenerated, one is supposed to re-dump Emacs. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 04:20:36 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 08:20:36 +0000 Received: from localhost ([127.0.0.1]:47633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM0PM-0007uy-1H for submit@debbugs.gnu.org; Mon, 02 Jun 2025 04:20:36 -0400 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:44377) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uM0PJ-0007uH-PC for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 04:20:34 -0400 Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-3a4fea34e07so886482f8f.1 for <78582@debbugs.gnu.org>; Mon, 02 Jun 2025 01:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748852427; x=1749457227; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=KSJBvJbiemH/o76JfGC1KsnTJmDer+UvnlIRSm/hjPE=; b=Do1dADelf+2NZJkLB4e8yXUE0GQF7vB4SJe/RdDRWLTK1t1R8yf1AmirVmLyk3bbKl pYFB5CP3VVQZA8t3+7v4kPOO4wj3Os965o7y2RNOVMLENsLio+N0XTObZc6ysYjzn6hl Hr2h37xQVfB8BoIUkXa5k94QsLGN4EnFiwxSP6WjkwCji2SIuKozolQIsBM/1E5ivH3T mgMl4gTw3LJSflxzDtYwNjJuJ22FEMTvm2LZOrdzE2xlVwwq5rdTMybggZ5OvZK9QiI2 gL5nhXISrV0DrlXxUpuLGqFxj44zPgN9+pdupKvlXw8c+yMU8hse/MLELwIQE1G4bFiU z9Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748852427; x=1749457227; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=KSJBvJbiemH/o76JfGC1KsnTJmDer+UvnlIRSm/hjPE=; b=gPB8lcGQs+bUGI+68t5K8benE6NWFZL5NrSBHtRpXWeRm/dAj5DQDXIccX1mxW7Hig +m/cLXApJDFvdU9MmP1GUF/UqeDQoSl27d1bcv/QowHK+hfskBdUYavltbJzvx/o+9x0 OKB5p7ymY/yip72OGCmSpmxq8ROF8TfHUeHpgartAEWSOC9KhJXl36YM7G9IbyAEc+JD 64NVhlOih5i+Xkl8og22UF6qCfi2ab/l+wAGD8O/QYmwbMclT0pNnLh0/BHWJMDrzfgf btmJp0KlVuxaL/BCcL6ZQeJv+S8blPvnttis2tMm4/AM7YEs8ZC7UWukLM5aHue1BkHx 9ZVw== X-Forwarded-Encrypted: i=1; AJvYcCX+T2rc/kgH61zNNf+9wiEAOf169xORisa+Jdlo+FNNIlTlSfny0yFb0K81840ckKplzyS1Xw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz5xhiA+g5fncGUV7r7K0mhK9sH+MV3WI04DWzI+8Gwuuzvg0ug 7YEJVNZ4TtiI6w+fQ+rdVzuym+LRrCeNtNPZj+gxBHDSmO694ASWXEFmmUwY396H X-Gm-Gg: ASbGncuJ1sphc474UfNC8JDc3Vn9iOzohBxHG9vPw13Fvp63fVicoFPr+hWhlozUcUi zlGDhc1lMJsKXK+jwOQND/xKiCY1JbuOc7Z4N5I/V+DZVhjgx0e/q/Vdn1hz8XbqeBzXv00eFie 1jPGF0sxLwl/mc3Ql7xCPKnXssTHpwnr61qwuiFVcac7UDAumUQKe8YHonjxvEyEyj0lA6t1cPZ QutycbjSPCgdXAKdTh8Cf+ZCHUIJYdP4nDTgjV7Y0dnkmCAlV9sdz8QFTBKN8g8MnveHi/k2u1s L5P+UUoeI5EMoRPhORtGFukMtDiVKE/c3B1ipNvRN62H0hJlR0SJTQG4MuPY9DBUh7WrTYz4dhI bedyZWY1VIdBwDEm8BYFhr3SDm/v1p2LGCmyqtiQV3Too1D6kHZVP2Uk= X-Google-Smtp-Source: AGHT+IHo0nnZ0kbW0yF4o36YBocF+5Ixd1435UPxpx8yc5ZF9+s11cMHTcfSL9cLpsd4uGOgrt5uTA== X-Received: by 2002:a05:6000:1447:b0:3a4:d41d:8f40 with SMTP id ffacd0b85a97d-3a4f7a6d2bcmr9026508f8f.46.1748852427040; Mon, 02 Jun 2025 01:20:27 -0700 (PDT) Received: from pro2 (p200300e0b72e350060f297ff9ecb4644.dip0.t-ipconnect.de. [2003:e0:b72e:3500:60f2:97ff:9ecb:4644]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4f00972b5sm14089708f8f.76.2025.06.02.01.20.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 01:20:26 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: <86ecw2pohw.fsf@gnu.org> References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86msaqppt7.fsf@gnu.org> <86ecw2pohw.fsf@gnu.org> Date: Mon, 02 Jun 2025 10:20:25 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: Stefan Monnier , murray.alex@gmail.com, >> luangruo@yahoo.com, 78582@debbugs.gnu.org >> Date: Mon, 02 Jun 2025 09:42:17 +0200 >>=20 >> Eli Zaretskii writes: >>=20 >> >> From: Gerd M=C3=B6llmann >> >> Cc: Alex Murray , Po Lu , >> >> 78582@debbugs.gnu.org >> >> Date: Mon, 02 Jun 2025 05:49:14 +0200 >> >>=20 >> >> Eli Zaretskii writes: >> >>=20 >> >> > Po Lu, any ideas why the PGTK build could show this strange behavio= r? >> >>=20 >> >> I encountered this on macOS today. Reproducer with an installed Emacs= =20 >> >> (which is the Emacs.app on macOS): >> >>=20 >> >> ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q >> >>=20 >> >> In *scratch*, eval >> >>=20 >> >> (global-set-key [f4] #'kill-current-buffer) >> >> (documentation 'rectangle-mark-mode) >> >>=20 >> >> Then C-h k and observe that it has been redefined. >> > >> > Not reproducible on my system with today's master branch. When I >> > press "C-h k " after evaluating the above line by line, I get the >> > expected documentation of kill-current-buffer. >>=20 >> It seems to depend on trying this in an installed Emacs, and that that >> Emacs is older than what is built in the repo that I built it in. For >> example, the Emacs I'm running is from some weeks ago when I started >> using the NS freeze workaround I posted to emacs-devel. In the repo, a >> more current Emacs is built. >>=20 >> >> A backtrace how this happens with which-key is at then end. In short, >> >> which-key calls 'documentation' which loads lisp/loaddefs which >> >> evaluates the global-set-keys loaddefs.el contains. >> > >> > "M-x debug-on-entry RET global-set-key RET" doesn't pop up the >> > debugger when I evaluate "(documentation 'rectangle-mark-mode)". >> > >> > Anyway, why would Emacs want to load loaddefs, when loaddefs is >> > preloaded? >>=20 >> Could be Fdocumentation: >>=20 >> doc.c: >> 365 if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc)))) >> 366 { >> 367 Lisp_Object tem =3D get_doc_string (doc, 0); >> 368 if (NILP (tem) && try_reload) >> 369 { >> 370 /* The file is newer, we need to reset the pointers. */ >> 371 reread_doc_file (Fcar_safe (doc)); >> 372 try_reload =3D false; >>=20 >>=20 >> doc.c: >> 310 static void >> 311 reread_doc_file (Lisp_Object file) >> 312 { >> 313 if (NILP (file)) >> 314 Fsnarf_documentation (Vdoc_file_name); >> 315 else >> 316 save_match_data_load (file, Qt, Qt, Qt, Qnil); >> 317 } >>=20 >> That's of course not the root cause, but somehow it's happening. > > So you are saying that the problem happens if Emacs is older than its > loaddefs.el? If so, this is not a situation we support, so I think > this bug is not a bug at all. When loaddefs is regenerated, one is > supposed to re-dump Emacs. No that doesn't seem to be the case. In the installed Emacs.app /Users/gerd/Desktop/Emacs.app/Contents/MacOS: -rwxr-xr-x 1 gerd staff 4678640 Jun 1 04:55 Emacs -rw-r--r-- 1 gerd staff 396932 Jun 1 04:55 loaddefs.el.gz -rw-r--r-- 1 gerd staff 1530577 Jun 1 04:55 loaddefs.elc -rw-r--r-- 1 gerd staff 991796 Jun 1 04:56 DOC The timestamps look okay. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 04:22:49 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 08:22:49 +0000 Received: from localhost ([127.0.0.1]:47655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM0RV-000837-0L for submit@debbugs.gnu.org; Mon, 02 Jun 2025 04:22:49 -0400 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:48569) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uM0RS-00082c-EP for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 04:22:46 -0400 Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-3a3758b122cso2698811f8f.1 for <78582@debbugs.gnu.org>; Mon, 02 Jun 2025 01:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748852560; x=1749457360; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=X++GPgoUPBFKR1/u7CthhI8awhvT2nqXElfJ0JIm7VU=; b=EmCgBgGSBJ+oHgIFoM+NsZijwFJnnMG4ikvF+4c2v4D/olJPJ0/KpU2DrK9DkuOgd9 T4dei4Bs+KgLFvrJRcWPosuOPYRkLv6dAkMbMGOhI7uFs3Xb8EzOpr9jJfePNRoTA1DW orRTMNW9R9fCbR5UkcARUVi0sv+weEE2SvPeWaWDEueDqlAQcp4GF88mGcBCOpS9auRp zhKZbe/SrCwFdmiBf0mpPQUS/8nLjKViKN3TZrHG3uJXDv64YGU5hjUcT6r88tw7c9Vl Fz359Df5LaYC4pp1rk8BpuKuPdjNbOF1IHKJv2eSjIZbt8ubIcp26kDJQLb6LgJbisBe bmDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748852560; x=1749457360; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=X++GPgoUPBFKR1/u7CthhI8awhvT2nqXElfJ0JIm7VU=; b=V4DO4YPFyGC4YcnU+EYjbchun3FxNYSgYUWZ3okWf0dOthOmYXL4k4haCJlC4hToeF sd0LpRBAL9XfodXvKKGjCca6KPjA5q+YWEJvQaKyo6mO+7J3GTTE/znXP7pMMjnH9lMF 87KXkaQzJB8FfK2DNy/IFcLDH7dEAFC2L5J7wuffofSpq1Y6v1RUMkuSJaKmCkkDhhMW ITtTGh53u3ocJ6A5iHu0kumT4mBe0uKG58ZL84oUk+DK9SpNw3vHJVY52AMmnzBY9Rb3 eTQ1VWW29nI4a5UTS/3Z/wBWZYrfQlZswm1eWgRFRzCMxIJtma8luOZQuO4lkzkx3r1j Qyaw== X-Forwarded-Encrypted: i=1; AJvYcCVsMSj7MhJk4LYMV9s7R+hhykxan1OCcxZLrgXShxm4tnW81DsZJRnO0vJ+n3FZT8q4JuyU+Q==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyzvCJ8iQqkV/6WINwzI1U5s8zZupUNZbRXnxy4zzmCvU1GQ5oz 6X3V8OSPPmU1vL6nEuMMSSiDMtNwlgZlqSYRFwCD8z1Pq/tbwQPybOu4WxhBRDc6 X-Gm-Gg: ASbGncul/X4vlvPt3z1s/jqJ84FZBD0+SuhH9K2D08R4yOHdGSLN2GB74PJxkuGQYUs HWjRJJR46JBMVZYyQ8pnNmGx5FlVLXVSZRyVAYRBOezH0qGYOfJXteoo67wNn0eirB+oqR8/mHB +16D/tiV3uGRZ72ymkiRWcctVC4YCCffLPXEn1TT8c0/YxZH/A9umLISNeG9z03FJ5uxVbWjiUS gHoZd62z/hmi3Ujamv3e1PTfyiNwn3Aw/M7bZN6bQ9DxzII2GGyDFSSmdsaplHShZYRSC2FL7m+ +YByXYi7SjzIs8JlA9VfMqV2xUXquLsmcdEj32DjKXKapHCogaqDIZfGqVXi3mKlc4Rnmunuwnx i20eZGq/jGwQKblxM9rN+j+53EBjGniamgkCj7ALiFt6zKACcMlQYlSQ= X-Google-Smtp-Source: AGHT+IHnrvBFLobP+7Et+Dn60P/gbIUbapEoTE2jH7U1wjWfj8QvwwWOL7wy01xBQ/yLmSoTc4KQhA== X-Received: by 2002:a05:6000:24c8:b0:3a4:f520:8bfc with SMTP id ffacd0b85a97d-3a4f7a9c504mr9069691f8f.36.1748852560019; Mon, 02 Jun 2025 01:22:40 -0700 (PDT) Received: from pro2 (p200300e0b72e350060f297ff9ecb4644.dip0.t-ipconnect.de. [2003:e0:b72e:3500:60f2:97ff:9ecb:4644]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4f0097813sm14187931f8f.72.2025.06.02.01.22.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 01:22:39 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: <86ldqapphd.fsf@gnu.org> References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> Date: Mon, 02 Jun 2025 10:22:38 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, Stefan Monnier , 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: Alex Murray , Po Lu , >> 78582@debbugs.gnu.org >> Date: Mon, 02 Jun 2025 06:24:12 +0200 >>=20 >> Gerd M=C3=B6llmann writes: >>=20 >> > I have no idea how to fix this. >>=20 >> In any case, code that changes global state like global-set-key does >> looks wrong in loaddefs.el. > > What's wrong with it? It's a direct effect of this part of kmacro.el: > > ;;; Provide some binding for startup: > ;;;###autoload (global-set-key "\C-x(" #'kmacro-start-macro) > ;;;###autoload (global-set-key "\C-x)" #'kmacro-end-macro) > ;;;###autoload (global-set-key "\C-xe" #'kmacro-end-and-call-macro) > ;;;###autoload (global-set-key [f3] #'kmacro-start-macro-or-insert-coun= ter) > ;;;###autoload (global-set-key [f4] #'kmacro-end-or-call-macro) > ;;;###autoload (global-set-key "\C-x\C-k" #'kmacro-keymap) > ;;;###autoload (autoload 'kmacro-keymap "kmacro" "Keymap for keyboard m= acro commands." t 'keymap) > > IOW, we do this on purpose, for the reasons explained in the comment. > Given that loaddefs is supposed toe be loaded just once, during > dumping, why is that wrong? I don't follow. I didn't say it was done unintentionally, and being done intentionally doesn't mean it's right. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 08:10:47 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 12:10:47 +0000 Received: from localhost ([127.0.0.1]:49738 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM406-0002Nd-FP for submit@debbugs.gnu.org; Mon, 02 Jun 2025 08:10:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39126) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uM403-0002Mt-KI for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 08:10:44 -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 ) id 1uM3zx-0003cI-5U; Mon, 02 Jun 2025 08:10:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=TZn4zgCS/HtnXQa7MB3MnCK7xRivV0k+WDYNNdJUssk=; b=L1mTGxSY5aYcSxxcY2sl UsoG40hWX4p/B+Jtk+lEhDwC7AwV18jvWNhbKHVkjbJyuxmheemfj1FVfBd4GiWU7laXQZrPEdIPF EJPzCgn7m8MDCr9D/7lXlXXkpNEYKgR3aeMK1U3HJTHGNy4HimKIKvOJanvLfRs5H9Ha6RJXDU8xC r9LBeRParK9vjbKcLRhjBPsSrRxgmoN/nSQFsIKUlUf07+sRd7wdKRgkx2LDM11CeRDqwosVum5KW Kj0OvwqEz/SNp9ub/oYd8Kawsh5v/NBmqxkhtpqLZzRLlIXitu4pL5N8oHAvU+tVa+A3zHqkP+J5x 38g4SC/ruv6sKA==; Date: Mon, 02 Jun 2025 15:09:55 +0300 Message-Id: <86cybmpcoc.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Mon, 02 Jun 2025 10:20:25 +0200) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86msaqppt7.fsf@gnu.org> <86ecw2pohw.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: monnier@iro.umontreal.ca, murray.alex@gmail.com, luangruo@yahoo.com, > 78582@debbugs.gnu.org > Date: Mon, 02 Jun 2025 10:20:25 +0200 > > Eli Zaretskii writes: > > >> From: Gerd Möllmann > >> Cc: Stefan Monnier , murray.alex@gmail.com, > >> luangruo@yahoo.com, 78582@debbugs.gnu.org > >> Date: Mon, 02 Jun 2025 09:42:17 +0200 > >> > >> Eli Zaretskii writes: > >> > >> >> From: Gerd Möllmann > >> >> Cc: Alex Murray , Po Lu , > >> >> 78582@debbugs.gnu.org > >> >> Date: Mon, 02 Jun 2025 05:49:14 +0200 > >> >> > >> >> Eli Zaretskii writes: > >> >> > >> >> > Po Lu, any ideas why the PGTK build could show this strange behavior? > >> >> > >> >> I encountered this on macOS today. Reproducer with an installed Emacs > >> >> (which is the Emacs.app on macOS): > >> >> > >> >> ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q > >> >> > >> >> In *scratch*, eval > >> >> > >> >> (global-set-key [f4] #'kill-current-buffer) > >> >> (documentation 'rectangle-mark-mode) > >> >> > >> >> Then C-h k and observe that it has been redefined. > >> > > >> > Not reproducible on my system with today's master branch. When I > >> > press "C-h k " after evaluating the above line by line, I get the > >> > expected documentation of kill-current-buffer. > >> > >> It seems to depend on trying this in an installed Emacs, and that that > >> Emacs is older than what is built in the repo that I built it in. For > >> example, the Emacs I'm running is from some weeks ago when I started > >> using the NS freeze workaround I posted to emacs-devel. In the repo, a > >> more current Emacs is built. > >> > >> >> A backtrace how this happens with which-key is at then end. In short, > >> >> which-key calls 'documentation' which loads lisp/loaddefs which > >> >> evaluates the global-set-keys loaddefs.el contains. > >> > > >> > "M-x debug-on-entry RET global-set-key RET" doesn't pop up the > >> > debugger when I evaluate "(documentation 'rectangle-mark-mode)". > >> > > >> > Anyway, why would Emacs want to load loaddefs, when loaddefs is > >> > preloaded? > >> > >> Could be Fdocumentation: > >> > >> doc.c: > >> 365 if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc)))) > >> 366 { > >> 367 Lisp_Object tem = get_doc_string (doc, 0); > >> 368 if (NILP (tem) && try_reload) > >> 369 { > >> 370 /* The file is newer, we need to reset the pointers. */ > >> 371 reread_doc_file (Fcar_safe (doc)); > >> 372 try_reload = false; > >> > >> > >> doc.c: > >> 310 static void > >> 311 reread_doc_file (Lisp_Object file) > >> 312 { > >> 313 if (NILP (file)) > >> 314 Fsnarf_documentation (Vdoc_file_name); > >> 315 else > >> 316 save_match_data_load (file, Qt, Qt, Qt, Qnil); > >> 317 } > >> > >> That's of course not the root cause, but somehow it's happening. > > > > So you are saying that the problem happens if Emacs is older than its > > loaddefs.el? If so, this is not a situation we support, so I think > > this bug is not a bug at all. When loaddefs is regenerated, one is > > supposed to re-dump Emacs. > > No that doesn't seem to be the case. In the installed Emacs.app > > /Users/gerd/Desktop/Emacs.app/Contents/MacOS: > -rwxr-xr-x 1 gerd staff 4678640 Jun 1 04:55 Emacs > > -rw-r--r-- 1 gerd staff 396932 Jun 1 04:55 loaddefs.el.gz > -rw-r--r-- 1 gerd staff 1530577 Jun 1 04:55 loaddefs.elc > > -rw-r--r-- 1 gerd staff 991796 Jun 1 04:56 DOC > > The timestamps look okay. But you seemed to be saying that the installed Emacs was for some reason loading loaddefs from the repo's worktree, which was newer: >> It seems to depend on trying this in an installed Emacs, and that that >> Emacs is older than what is built in the repo that I built it in. For >> example, the Emacs I'm running is from some weeks ago when I started >> using the NS freeze workaround I posted to emacs-devel. In the repo, a >> more current Emacs is built. Did I misunderstand? My point is that if Emacs for some reason loads a newer loaddefs, that is not a situation that is expected. maybe we should understand why that newer loaddefs is being loaded in your case. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 08:12:44 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 12:12:44 +0000 Received: from localhost ([127.0.0.1]:49750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM420-0002Tz-0t for submit@debbugs.gnu.org; Mon, 02 Jun 2025 08:12:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41886) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uM41x-0002Td-QU for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 08:12:42 -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 ) id 1uM41s-0003mV-4P; Mon, 02 Jun 2025 08:12:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=RCV2r2O8zdqh6Ia7K4Mp7BnZe59o4+2rSOkBDHy6XRw=; b=V1YriqLN5KJ608uC5DiV S2wx2cw3nZX3Zgm39B1rvEOGXjfUSH7Nd3uEXnyEY7fNv6Vb8534+o3mwx+2bdmZPXymbiFQ09DY/ cWW77VRDGWKLfvMRd6P0m92fSpdoeCci5qqBj0GShbAskFsknBW4E7YPQUkzzcZeUg6KDCgxhpHzY MxFyOf0IN7cHQ/YZcJuugSbD2z1rPCkjpPZ1y/3+17yG2h531+ANE63MzlrI9ruHHWEwtQWd/krGm Faa1N23zLQfm7GL1LeVmt3qsniI7W5guQOR1CAr6LOjiQF3MNSlCmnOuQkH0fpxVGCi6pgK9p6KdU bqVjwvfFog/TPw==; Date: Mon, 02 Jun 2025 15:12:22 +0300 Message-Id: <86bjr6pck9.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Mon, 02 Jun 2025 10:22:38 +0200) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: Stefan Monnier , murray.alex@gmail.com, > luangruo@yahoo.com, 78582@debbugs.gnu.org > Date: Mon, 02 Jun 2025 10:22:38 +0200 > > Eli Zaretskii writes: > > >> From: Gerd Möllmann > >> Cc: Alex Murray , Po Lu , > >> 78582@debbugs.gnu.org > >> Date: Mon, 02 Jun 2025 06:24:12 +0200 > >> > >> Gerd Möllmann writes: > >> > >> > I have no idea how to fix this. > >> > >> In any case, code that changes global state like global-set-key does > >> looks wrong in loaddefs.el. > > > > What's wrong with it? It's a direct effect of this part of kmacro.el: > > > > ;;; Provide some binding for startup: > > ;;;###autoload (global-set-key "\C-x(" #'kmacro-start-macro) > > ;;;###autoload (global-set-key "\C-x)" #'kmacro-end-macro) > > ;;;###autoload (global-set-key "\C-xe" #'kmacro-end-and-call-macro) > > ;;;###autoload (global-set-key [f3] #'kmacro-start-macro-or-insert-counter) > > ;;;###autoload (global-set-key [f4] #'kmacro-end-or-call-macro) > > ;;;###autoload (global-set-key "\C-x\C-k" #'kmacro-keymap) > > ;;;###autoload (autoload 'kmacro-keymap "kmacro" "Keymap for keyboard macro commands." t 'keymap) > > > > IOW, we do this on purpose, for the reasons explained in the comment. > > Given that loaddefs is supposed toe be loaded just once, during > > dumping, why is that wrong? > > I don't follow. I didn't say it was done unintentionally, and being done > intentionally doesn't mean it's right. Not it general, but please tell what is wrong with the logic I described above that is at work in this particular case. Are you saying that it is wrong to expect loaddefs not be loaded by a running Emacs session? If so, please tell why. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 08:30:41 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 12:30:41 +0000 Received: from localhost ([127.0.0.1]:49905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM4JM-0003mC-Ae for submit@debbugs.gnu.org; Mon, 02 Jun 2025 08:30:41 -0400 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:47168) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uM4JJ-0003la-4e for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 08:30:38 -0400 Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3a50fc819f2so345901f8f.2 for <78582@debbugs.gnu.org>; Mon, 02 Jun 2025 05:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748867431; x=1749472231; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=aYyBewFFoHJIecL166RHh/d+QX0D8tpR/klvOaygi9o=; b=khBrhIRbYbWHJRQ6Y072c0V0uFDUIgl34fdoKRl/Rf5wbyDM7tDJ6X2V3+DEAqAero lEvfCDHyLzttFl73bcJQGs3kLvONbTtHBQBPmyYEWaUtDp0dOg2ik+l7kKgZkG+R/SQH KhZYtlyMMtaa07owAfcJk90JgCVVgdxqNmcoE03mW4aaSoYa+wHIxoHwm5ZhMGXCzwKL XJJITRx4AM5WRQC3r4YEUMgu2itLke/A5oLTRJLpvYXHcBh2fT4U8flPPewbc+tsvZ6l AYjMqvixx/hq8s3duyremlN8tYNC6AoCOdgWB8fPLoi9WrCpAfpsu2bM6SQI3l+Cc/c9 hfyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748867431; x=1749472231; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=aYyBewFFoHJIecL166RHh/d+QX0D8tpR/klvOaygi9o=; b=VJUEE1+A7JJ5uiXFjwtLcruyB2PWcKjE89/6IQD1+UuaqReBgt0VzxEFXRaylUDwsW YndOP3FmbTEm+feUGMyCKwtwv98GFLIZBqW8nUg3ofQ5A1VOhj61sEQtIj4CBlC6jyFy uBJyWUf2GLSmzPZwiXE/SqJznAULf1Cq6kLL0gTo9D9mCpBA8ku/eVa+TeIXwjkp12JL 7uNGFp3WQZBcfY2CQgKmWKVyAWVI0l5fTdpf/wPyHIsv5VZMSz2JrVRzivkxSYAIqeac om+6tmsKZW3l8kH/uaLomRHL2v7gNiLGYPy2Ay+g05rwNSkRrxwfyq83wK4eMBr1fLIq sygg== X-Forwarded-Encrypted: i=1; AJvYcCXjyXu2F2TRrYl6ODscIPjNBkVXdMNju3kh5/S8KGjsgzSt6ukfMsSHDFcugMrmX7NP9oONKg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwudmPKbWX9hyOvUZQmCUxLbx9RdHkeNgrN5XGhvPTj8o+CIgoD smdb3NnZ4iMUfibq+c/lkF0JbcniuK3zKqd2VCo1bgoYtwEqjGHnWFx/YrX2h+41 X-Gm-Gg: ASbGncvY2yKNqD1CZnCWo+32eGlis4vMaRXQbPmCvcAWuCKUczdj/tAtIQ/tV9rmMLG shvl9xwyt9s7dDnqQ6zKRaD5FEJaKdX0ZtAHNzOWmnbKYwDZEzyIATImabfhYyjLHWxR6AHsuEN FM29AiItVB8/qUmpPCrY8WCOULVtNQFthai3rIe+KJpdMx+5DFqhdS+5Hndi6ogOF6sGu1jnbeG D5QfqSbU1ORwYjl13KYjok+8ho0Jh1UYCfrVrQq6+vpyMV2gB5HpM0QcEh11YCh2GxHkdI+WhbJ RlTMFSXYT2cPq34I+xL5F92XPc3gYdJSl9NboX3BzMLxuuQ+InMm0LBcY7O/5TWRHT3D2HP34in KvqPMTeUlgkBSxTMyEndWFdoMpgnBCCBH3oj7uDMZLZUSdTd4Q9PtdyE= X-Google-Smtp-Source: AGHT+IHtjH1RRS6lpVsjjNa4KtTFe9dTe+SgqJHephkR2zFlsGXDhk77LoG//tZmINLvwxcDNhoxUA== X-Received: by 2002:a05:6000:40c8:b0:3a4:d83a:eb4c with SMTP id ffacd0b85a97d-3a4f7ab1c5emr10355017f8f.57.1748867430395; Mon, 02 Jun 2025 05:30:30 -0700 (PDT) Received: from pro2 (p200300e0b72e350060f297ff9ecb4644.dip0.t-ipconnect.de. [2003:e0:b72e:3500:60f2:97ff:9ecb:4644]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe5b96fsm14589219f8f.8.2025.06.02.05.30.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 05:30:29 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: <86cybmpcoc.fsf@gnu.org> References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86msaqppt7.fsf@gnu.org> <86ecw2pohw.fsf@gnu.org> <86cybmpcoc.fsf@gnu.org> Date: Mon, 02 Jun 2025 14:30:29 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: monnier@iro.umontreal.ca, murray.alex@gmail.com, luangruo@yahoo.co= m, >> 78582@debbugs.gnu.org >> Date: Mon, 02 Jun 2025 10:20:25 +0200 >>=20 >> Eli Zaretskii writes: >>=20 >> >> From: Gerd M=C3=B6llmann >> >> Cc: Stefan Monnier , murray.alex@gmail.com, >> >> luangruo@yahoo.com, 78582@debbugs.gnu.org >> >> Date: Mon, 02 Jun 2025 09:42:17 +0200 >> >>=20 >> >> Eli Zaretskii writes: >> >>=20 >> >> >> From: Gerd M=C3=B6llmann >> >> >> Cc: Alex Murray , Po Lu , >> >> >> 78582@debbugs.gnu.org >> >> >> Date: Mon, 02 Jun 2025 05:49:14 +0200 >> >> >>=20 >> >> >> Eli Zaretskii writes: >> >> >>=20 >> >> >> > Po Lu, any ideas why the PGTK build could show this strange beha= vior? >> >> >>=20 >> >> >> I encountered this on macOS today. Reproducer with an installed Em= acs=20 >> >> >> (which is the Emacs.app on macOS): >> >> >>=20 >> >> >> ~/Desktop/Emacs.app/Contents/MacOS/Emacs -q >> >> >>=20 >> >> >> In *scratch*, eval >> >> >>=20 >> >> >> (global-set-key [f4] #'kill-current-buffer) >> >> >> (documentation 'rectangle-mark-mode) >> >> >>=20 >> >> >> Then C-h k and observe that it has been redefined. >> >> > >> >> > Not reproducible on my system with today's master branch. When I >> >> > press "C-h k " after evaluating the above line by line, I get t= he >> >> > expected documentation of kill-current-buffer. >> >>=20 >> >> It seems to depend on trying this in an installed Emacs, and that that >> >> Emacs is older than what is built in the repo that I built it in. For >> >> example, the Emacs I'm running is from some weeks ago when I started >> >> using the NS freeze workaround I posted to emacs-devel. In the repo, a >> >> more current Emacs is built. >> >>=20 >> >> >> A backtrace how this happens with which-key is at then end. In sho= rt, >> >> >> which-key calls 'documentation' which loads lisp/loaddefs which >> >> >> evaluates the global-set-keys loaddefs.el contains. >> >> > >> >> > "M-x debug-on-entry RET global-set-key RET" doesn't pop up the >> >> > debugger when I evaluate "(documentation 'rectangle-mark-mode)". >> >> > >> >> > Anyway, why would Emacs want to load loaddefs, when loaddefs is >> >> > preloaded? >> >>=20 >> >> Could be Fdocumentation: >> >>=20 >> >> doc.c: >> >> 365 if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc)))) >> >> 366 { >> >> 367 Lisp_Object tem =3D get_doc_string (doc, 0); >> >> 368 if (NILP (tem) && try_reload) >> >> 369 { >> >> 370 /* The file is newer, we need to reset the pointers. = */ >> >> 371 reread_doc_file (Fcar_safe (doc)); >> >> 372 try_reload =3D false; >> >>=20 >> >>=20 >> >> doc.c: >> >> 310 static void >> >> 311 reread_doc_file (Lisp_Object file) >> >> 312 { >> >> 313 if (NILP (file)) >> >> 314 Fsnarf_documentation (Vdoc_file_name); >> >> 315 else >> >> 316 save_match_data_load (file, Qt, Qt, Qt, Qnil); >> >> 317 } >> >>=20 >> >> That's of course not the root cause, but somehow it's happening. >> > >> > So you are saying that the problem happens if Emacs is older than its >> > loaddefs.el? If so, this is not a situation we support, so I think >> > this bug is not a bug at all. When loaddefs is regenerated, one is >> > supposed to re-dump Emacs. >>=20 >> No that doesn't seem to be the case. In the installed Emacs.app >>=20 >> /Users/gerd/Desktop/Emacs.app/Contents/MacOS: >> -rwxr-xr-x 1 gerd staff 4678640 Jun 1 04:55 Emacs >>=20 >> -rw-r--r-- 1 gerd staff 396932 Jun 1 04:55 loaddefs.el.gz >> -rw-r--r-- 1 gerd staff 1530577 Jun 1 04:55 loaddefs.elc >>=20 >> -rw-r--r-- 1 gerd staff 991796 Jun 1 04:56 DOC >>=20 >> The timestamps look okay. > > But you seemed to be saying that the installed Emacs was for some > reason loading loaddefs from the repo's worktree, which was newer: I believe it's loading the loaddefs.el from the installation because of this part of the backtrace I sent in the first mail global-set-key("\30(" kmacro-start-macro) byte-code("\300\301\302\303\304$\210\305\302\306\"\210\307\310\311\"\210\= 307\312\313\"\210\307\314\315\"\210\307\316\317\"\210\307\320\321\"\210\307= \322\323\"\210\300\323\324\325\304\326%\210\327\330\331\332#\210\333\330\33= 1\334#\210\300\311\324\335\304$\210\300\313\324\336\304$\210\300\337\324\34= 0\304$\210\300\317\324\341\304$\210\300\321\324\342\304$\210\300\315\324\34= 3\304$\210\300\344\324\345\304$\210\300\346\324\347#\210\300\350\324\351#\2= 10\333\350\346\334#\210\300\352\324\353\304$\210\327\354\355\"\210\300\355\= 324\356\304$\210\305\324\357\"\207" [autoload kkc-region "kkc" ("/Users/ger= d/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 768162) t regis= ter-definition-prefixes ("kkc-") global-set-key "\30(" kmacro-start-macro "= \30)" kmacro-end-macro "\30e" kmacro-end-and-call-macro [f3] kmacro-start-m= acro-or-insert-counter [f4] kmacro-end-or-call-macro "\30\13" kmacro-keymap= "kmacro" ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.= elc" . 768555) keymap defalias kmacro-exec-ring-item funcall "Execute item = ITEM from the macro ring.\nARG is the number of times to execute the item."= make-obsolete "29.1" ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/li= sp/loaddefs.elc" . 768689) ("/Users/gerd/Desktop/Emacs.app/Contents/Resourc= es/lisp/loaddefs.elc" . 769692) kmacro-call-macro ("/Users/gerd/Desktop/Ema= cs.app/Contents/Resources/lisp/loaddefs.elc" . 770110) ("/Users/gerd/Deskto= p/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 770706) ("/Users/gerd/D= esktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 771651) ("/Users/g= erd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 771871) kmacr= o-end-call-mouse ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/lo= addefs.elc" . 772193) kmacro ("/Users/gerd/Desktop/Emacs.app/Contents/Resou= rces/lisp/loaddefs.elc" . 772352) kmacro-lambda-form ("/Users/gerd/Desktop/= Emacs.app/Contents/Resources/lisp/loaddefs.elc" . 772507) kmacro-name-last-= macro ("/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/loaddefs.elc"= . 772549) kmacro-menu list-keyboard-macros ("/Users/gerd/Desktop/Emacs.app= /Contents/Resources/lisp/loaddefs.elc" . 772804) ("kmacro-")] 6) documentation(rectangle-mark-mode) which mentions the file. No way to be 100% sure though, and it's not a debug build, so I can't look. > >>> It seems to depend on trying this in an installed Emacs, and that that >>> Emacs is older than what is built in the repo that I built it in. For >>> example, the Emacs I'm running is from some weeks ago when I started >>> using the NS freeze workaround I posted to emacs-devel. In the repo, a >>> more current Emacs is built. > > Did I misunderstand? My point is that if Emacs for some reason loads > a newer loaddefs, that is not a situation that is expected. maybe we > should understand why that newer loaddefs is being loaded in your > case. I don't know what's going on either. When I build a new Emacs.app and run that (even from the sasme commit ID), the problem does not occur. When I start the older Emacs.app it does =F0=9F=A4=B7. Without debug info a= nd having it in LLDB, it's all guess work. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 08:47:04 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 12:47:04 +0000 Received: from localhost ([127.0.0.1]:50057 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM4ZD-0004xg-Ea for submit@debbugs.gnu.org; Mon, 02 Jun 2025 08:47:04 -0400 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:44206) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uM4ZB-0004wt-M3 for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 08:47:02 -0400 Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-3a375e72473so2495796f8f.0 for <78582@debbugs.gnu.org>; Mon, 02 Jun 2025 05:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748868415; x=1749473215; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=tGYg6eYYckwevPFHZi1E7eQlTd1ClwtEXPrPti+vf7Q=; b=QsqiSd4cpFzpZ1x1JL7inM63pqcuT3XL8q8TvuXp3rOy9GsTm3FPciHkyQv4KQl15l EakDEYS6k52mcTxM1hvpbTv+ovFuWvrcEhFX3hF3g6tCHjBiMBQLf9VNoe/vw6dD7AxP +K1av3YTHIHo4FYi5CalMUsnUEaUyOoNaR0NPF3aXTyxJiKWVHVI5iqY4eBvWp87TRxi 9eYKgK2DksX1Jnnkx1S3Zrx6gRCJwFVr7yZrinyWXclC2Ov68PQXkrf/K4ItejT6jMC8 +tnkdsFbQK33shBPEaoPIcbFFl4dma7RKwqtopK6d9wZEIS2AKAwZhhQmsQ3JVd6Imou NlYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748868415; x=1749473215; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=tGYg6eYYckwevPFHZi1E7eQlTd1ClwtEXPrPti+vf7Q=; b=OVk1HWC8Y/Idk2PwKTKTAOsSfAcbjq+7/cYCYVdvBG6fSGpHOXf1KkLmle84cWBcDp gyhGb5/1imxWKZKvobzGBbeBVimdN6h8aQbPpC327yNhd5gAkkmbaWygC00+sDP932c+ 8VVEuTHTx1zETkgMAayG8UeCB2VI6ePAwagckKaVNJK4ucPPIWxCD9KZW4kHAiKEIDke uVqgB3rMMXOpsNT60w9ksG+VBGbELg1xLx7oMtjS8eiFHlA3MSbDlgSezmUBH3RGTrwg VIB3C2DqDQx4a6fAEFTsFciQvydO6axhsGnpOHDtVyjoEFjIXkWryS/EmViMUrAuN940 kA+g== X-Forwarded-Encrypted: i=1; AJvYcCWSl70OxPR2ZEKOrlxgGhjwAFcMXK4yGrWsvJKgGHd8ad0E3qyPcroxrH4fwPzfK1naF3HS7Q==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxQEN7RWAXqWNLz9zByNscLr44XEP3FXzOFWCTBBX8/Fl2M9ksJ fzpnGXIK034OBgR0fIwdiPCJQjDDpNbKNpthDCrjZ+ciGlR9KbG9cCkTjNh4bWsn X-Gm-Gg: ASbGncuH8hRTO+TczSA64DukpAJadCbq8Ghf7CiDRlN+2L5sK+I1Rd9azHZgRqSZ2P/ o7+cyn4s8B6suEuloTh4pcNV8vEgVZIxT7vq1bE7hGYE/dXzHc0Xl+lHQYliB2i6t3383+z78Vw PI02/CdRG83C1ml7l1Af29flgR8npfW9mip4dIZzAiXxBvdvtyO77jIfUlhXQSooNkOLXuZPkRG 8X/eo6CV+mrDl7Kwsu90zDdguOd9VIs6yPs/MZvhXw3iTLtPC3WoooGNu+4NhvJX0nPdBBpb8tC YDf5Xsk8AKWWDBmRpr17rY8D9Vqo7q3/6mskQIrO4mVwkBahm7N44YpT+r9+wmUZvPzI5nvDx2b oUzHpOMA7VLFH181Naw/MPcJqhGaYrY5djXROf/8at6JA1nd7OUlozmKlWqZ4IU+ADg== X-Google-Smtp-Source: AGHT+IHw1IOsru45vyNp7D6VRrSwBfOccvYlJ1f3w8/Wzj9V2ptozBMALJ3FxDLWucisS7XwFl0OaA== X-Received: by 2002:a05:6000:2081:b0:3a4:ef48:23db with SMTP id ffacd0b85a97d-3a4f7a86346mr10733741f8f.59.1748868415118; Mon, 02 Jun 2025 05:46:55 -0700 (PDT) Received: from pro2 (p200300e0b72e350060f297ff9ecb4644.dip0.t-ipconnect.de. [2003:e0:b72e:3500:60f2:97ff:9ecb:4644]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe73f01sm14437036f8f.45.2025.06.02.05.46.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 05:46:54 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: <86bjr6pck9.fsf@gnu.org> References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> Date: Mon, 02 Jun 2025 14:46:53 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: Stefan Monnier , murray.alex@gmail.com, >> luangruo@yahoo.com, 78582@debbugs.gnu.org >> Date: Mon, 02 Jun 2025 10:22:38 +0200 >>=20 >> Eli Zaretskii writes: >>=20 >> >> From: Gerd M=C3=B6llmann >> >> Cc: Alex Murray , Po Lu , >> >> 78582@debbugs.gnu.org >> >> Date: Mon, 02 Jun 2025 06:24:12 +0200 >> >>=20 >> >> Gerd M=C3=B6llmann writes: >> >>=20 >> >> > I have no idea how to fix this. >> >>=20 >> >> In any case, code that changes global state like global-set-key does >> >> looks wrong in loaddefs.el. >> > >> > What's wrong with it? It's a direct effect of this part of kmacro.el: >> > >> > ;;; Provide some binding for startup: >> > ;;;###autoload (global-set-key "\C-x(" #'kmacro-start-macro) >> > ;;;###autoload (global-set-key "\C-x)" #'kmacro-end-macro) >> > ;;;###autoload (global-set-key "\C-xe" #'kmacro-end-and-call-macro) >> > ;;;###autoload (global-set-key [f3] #'kmacro-start-macro-or-insert-c= ounter) >> > ;;;###autoload (global-set-key [f4] #'kmacro-end-or-call-macro) >> > ;;;###autoload (global-set-key "\C-x\C-k" #'kmacro-keymap) >> > ;;;###autoload (autoload 'kmacro-keymap "kmacro" "Keymap for keyboar= d macro commands." t 'keymap) >> > >> > IOW, we do this on purpose, for the reasons explained in the comment. >> > Given that loaddefs is supposed toe be loaded just once, during >> > dumping, why is that wrong? >>=20 >> I don't follow. I didn't say it was done unintentionally, and being done >> intentionally doesn't mean it's right. > > Not it general, but please tell what is wrong with the logic I > described above that is at work in this particular case. Are you > saying that it is wrong to expect loaddefs not be loaded by a running > Emacs session? If so, please tell why. AFAICT, the code in Fdocumentation can reload doc strings from files. I showed reread_doc_file. doc.c: 310 static void 311 reread_doc_file (Lisp_Object file) 312 { 313 if (NILP (file)) 314 Fsnarf_documentation (Vdoc_file_name); 315 else 316 save_match_data_load (file, Qt, Qt, Qt, Qnil); 317 } Secondly, doc strings can point to loaddefs.el (function-documentation 'rectangle-mark-mode) =3D> ("loaddefs.elc" . 1059343) in the Emacs I'm writing this. Both together mean that loaddefs can be loaded when the path through reread_doc_file is taken. Not that I know why it happens, but it does happen, as this case demonstrates. Code that prevents loaddefs specifically from being loaded I can't find. Maybe it was just an assumption that this never happens and something was changed that made the assumption being wrong? Don't know. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 08:49:55 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 12:49:55 +0000 Received: from localhost ([127.0.0.1]:50092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM4by-00056l-O1 for submit@debbugs.gnu.org; Mon, 02 Jun 2025 08:49:55 -0400 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:49367) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uM4bv-00056J-M1 for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 08:49:52 -0400 Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-450cb2ddd46so25997135e9.2 for <78582@debbugs.gnu.org>; Mon, 02 Jun 2025 05:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748868585; x=1749473385; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=TUftHF0hkh+6XFiDIDyrUjfbI+cyZE98ieFpIQrWW5w=; b=SkRwgDHI7FHNxrWT/gnguKb2t58l7jFtnIH8u9q6S2/eO01bNqXHe0hKZsZFhOB+AS 3uS4ZjSlkYc/m5JfwDQlUlgl43AZd+0ai3Odv1HW5glkfBqtIoy9I9dce2W6N8VJbIy2 1Wcs4p94zNDVFCqbjsHpWMOHjVNmPXvAItFqnxSsZ709SbUgA/STZ1ne3fhB6pm4zxJn OMsRy9dLtq+lV0PgUp4yJsWAN3P/SJMfzSXwUgDlqfAnV6E2MHqUlolOZG2uNplPSrwo V9jWf03Y40VK2Cbv2bR04DUXjVynlliF4WQmARDrxYWWkTWx5g/h/wUs2jeEqvP3BvtW 7zaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748868585; x=1749473385; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=TUftHF0hkh+6XFiDIDyrUjfbI+cyZE98ieFpIQrWW5w=; b=ZKuItZl+Q6G3sjMwGCohZNkg5ECCVdJcsLjZYPxb0pFAoOWu9tE2PUSr9541ijoCAC 1/3jj5MiaGgRN/U68ugXLm17bXMofaL0lM+1RzRTCi/gvv9eKH3I85evlJMUKYCqjkQf iJbxKi+GNMH39DQmF/tQsIfjhWsj7P3SAzZL+Af62VAer272WhdYBQcuPYWSnlUmJKBX fa9YLiszo+kBSdargewXvtWaNjyFJf21fSHbvsGrZV6ZckkeOGWlUfjV7Iy6dS98YZDi VnrxI9DTbQQS2YVAfvOx4fs6XumFhK0EjvdTakoXDL0t4wUvMoD0Fiy0Od2EosN9Vp+m WBpQ== X-Forwarded-Encrypted: i=1; AJvYcCUN6dvQfJxp0nKxNNj+51raxT8skTAbRzroF+g9zGDY/POGH+z1Bj91tP0X6LQOYPlOdGwsXQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxKxfrGPKyIPcDTfgR5wfHEQdNgUy64106mBzlxOfLofHWGyZJ7 fV+Ov2tRQ6rKn4r0OaJaXaOereAhU11CPL9/dOXpi8lo13MZJslC/RWCKuMf+ehv X-Gm-Gg: ASbGncvULqWfrwNwFWrwijTOHBsFeTrzr476KES+4kfaJlMrCvZj07o2Td6OuNQrx34 1xr3ZM2YzoNiNDiF5sVGmv/Dcu1H0gAkSL6X6slUzzM30InjBszcPbNs9FpZE3UTFYcPsIjZKTK EUJRYY+/2IZzTReYm3HGJubXyXH8wPCorxpxbBr0re1SMaoc4ZUHIQD2IdsdIHbtnrzx2VBnyc8 1avODOcUlFdXoqpkPd1HKeYOm3OVnVU32g0aN9EWYaHeEmLQvPwlhYPFpo6gYoS+G+y2JteYG2z hoo/ZFta57y2LkhreDAz7tN6LHTpIa7GTRAgAyuRtxig8WYX7m7l29U9g7GVNNqz5XxAjX6bpXj HM+X94JXP8V1Xim5NJLwSEMZHgxA0vIEFqjEQhEt534RjC4p3vFfGp/o= X-Google-Smtp-Source: AGHT+IH/VyIn5ih47PObuZmYekCTBSzSEvZRA6MOav6AxpmignyBvHr+gZ8qlYd76QUX4pdiKCczPA== X-Received: by 2002:a05:600c:8207:b0:450:6b55:cf91 with SMTP id 5b1f17b1804b1-450d64c1bd9mr109202085e9.6.1748868584712; Mon, 02 Jun 2025 05:49:44 -0700 (PDT) Received: from pro2 (p200300e0b72e350060f297ff9ecb4644.dip0.t-ipconnect.de. [2003:e0:b72e:3500:60f2:97ff:9ecb:4644]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-450d7fb051bsm120520965e9.18.2025.06.02.05.49.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 05:49:44 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> Date: Mon, 02 Jun 2025 14:49:43 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Eli Zaretskii writes: > >>> From: Gerd M=C3=B6llmann >>> Cc: Stefan Monnier , murray.alex@gmail.com, >>> luangruo@yahoo.com, 78582@debbugs.gnu.org >>> Date: Mon, 02 Jun 2025 10:22:38 +0200 >>>=20 >>> Eli Zaretskii writes: >>>=20 >>> >> From: Gerd M=C3=B6llmann >>> >> Cc: Alex Murray , Po Lu , >>> >> 78582@debbugs.gnu.org >>> >> Date: Mon, 02 Jun 2025 06:24:12 +0200 >>> >>=20 >>> >> Gerd M=C3=B6llmann writes: >>> >>=20 >>> >> > I have no idea how to fix this. >>> >>=20 >>> >> In any case, code that changes global state like global-set-key does >>> >> looks wrong in loaddefs.el. >>> > >>> > What's wrong with it? It's a direct effect of this part of kmacro.el: >>> > >>> > ;;; Provide some binding for startup: >>> > ;;;###autoload (global-set-key "\C-x(" #'kmacro-start-macro) >>> > ;;;###autoload (global-set-key "\C-x)" #'kmacro-end-macro) >>> > ;;;###autoload (global-set-key "\C-xe" #'kmacro-end-and-call-macro) >>> > ;;;###autoload (global-set-key [f3] #'kmacro-start-macro-or-insert-= counter) >>> > ;;;###autoload (global-set-key [f4] #'kmacro-end-or-call-macro) >>> > ;;;###autoload (global-set-key "\C-x\C-k" #'kmacro-keymap) >>> > ;;;###autoload (autoload 'kmacro-keymap "kmacro" "Keymap for keyboa= rd macro commands." t 'keymap) >>> > >>> > IOW, we do this on purpose, for the reasons explained in the comment. >>> > Given that loaddefs is supposed toe be loaded just once, during >>> > dumping, why is that wrong? >>>=20 >>> I don't follow. I didn't say it was done unintentionally, and being done >>> intentionally doesn't mean it's right. >> >> Not it general, but please tell what is wrong with the logic I >> described above that is at work in this particular case. Are you >> saying that it is wrong to expect loaddefs not be loaded by a running >> Emacs session? If so, please tell why. > > AFAICT, the code in Fdocumentation can reload doc strings from files. I > showed reread_doc_file. > > doc.c: > 310 static void > 311 reread_doc_file (Lisp_Object file) > 312 { > 313 if (NILP (file)) > 314 Fsnarf_documentation (Vdoc_file_name); > 315 else > 316 save_match_data_load (file, Qt, Qt, Qt, Qnil); > 317 } > > Secondly, doc strings can point to loaddefs.el > > (function-documentation 'rectangle-mark-mode) > =3D> ("loaddefs.elc" . 1059343) > > in the Emacs I'm writing this. > > Both together mean that loaddefs can be loaded when the path through > reread_doc_file is taken. Not that I know why it happens, but it does > happen, as this case demonstrates. > > Code that prevents loaddefs specifically from being loaded I can't find. > Maybe it was just an assumption that this never happens and something > was changed that made the assumption being wrong? Don't know. Forgot to mention: kmacro and smerge seem to be the only ones using this "global-set-key in loaddefs" mechanism. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 10:11:30 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 14:11:30 +0000 Received: from localhost ([127.0.0.1]:52294 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM5sw-00064L-4i for submit@debbugs.gnu.org; Mon, 02 Jun 2025 10:11:30 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26123) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uM5st-00063q-4O for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 10:11:27 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C762B4413B9; Mon, 2 Jun 2025 10:11:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1748873478; bh=6EotuyalQwR/vH9ZR0GnPwas2718iiuZ1Wl/yfX6I1Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=H17h5rygKEFLl9bGnmf/q8kCKPw590/n4FTbSb5hZtc4eDk1/vaEU5VLsMeITziS5 dDEzKVlBK+/UhtCZflXDIdCdtuiapSuPq4vp3KQWVc3tAyLAxbyXOwgDT15g8SMHmO xLuTFs0BEMmPt/C5feYE1O2G52cxpJX70xewYjTda0l/FBt1ySUkeppftlTpiDYRh9 d/KNJrwESY6WgjYBzimkkfD+IQIE7NU8tLx2ZdAFLlZTp18NqlVnIyXVIZsxT6+Bjz j89dcmlDZmD7/KUI0xw13zVfmwhRwd3Qm3/eiFHjB6bSB9Om7w90kXfxxCynHySPAP ryE5gtBuR5RKg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E08F54413A0; Mon, 2 Jun 2025 10:11:18 -0400 (EDT) Received: from alfajor (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8B7CB1204B4; Mon, 2 Jun 2025 10:11:18 -0400 (EDT) From: Stefan Monnier To: Gerd =?windows-1252?Q?M=F6llmann?= Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: Message-ID: References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> Date: Mon, 02 Jun 2025 10:11:16 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.337 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, Eli Zaretskii , 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > doc.c: > 310 static void > 311 reread_doc_file (Lisp_Object file) > 312 { > 313 if (NILP (file)) > 314 Fsnarf_documentation (Vdoc_file_name); > 315 else > 316 save_match_data_load (file, Qt, Qt, Qt, Qnil); > 317 } > > Secondly, doc strings can point to loaddefs.el > > (function-documentation 'rectangle-mark-mode) > =3D> ("loaddefs.elc" . 1059343) AFAICT the problem you describe is not specific to `loaddefs.el`. The same thing can happen with any file that has a `global-set-key` call at top-level. This reloading business is supposed to happen only if the in-memory doc-string-reference is out-of-sync with the installed files, presumably because you're running Emacs "in place" and the files have changed in the mean time. If that's indeed your situation, then "all is well": the problem you're seeing is "on purpose". You can fix it by removing the above reloading mechanism (in exchange for being unable to see the docstring in those cases where the reloading would be needed). I tend to see this every once in a while where `C-x C-c` (which I normally rebind to a less-drastic operation) gets redefined to its default binding because `files.elc` gets reloaded. =F0=9F=99=82 Maybe we should try and work harder to make such reloading more harmless (e.g. replace the `define-key/global-set-key`s with functions which do nothing if the key is already bound?), but it's an issue that affects only those people who hack on the code of the very Emacs they're running, so it's not super-high priority. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 10:27:02 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 14:27:02 +0000 Received: from localhost ([127.0.0.1]:52464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM67y-0007Dw-4V for submit@debbugs.gnu.org; Mon, 02 Jun 2025 10:27:02 -0400 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:53467) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uM67u-0007DC-2p for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 10:26:59 -0400 Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3a36748920cso5145050f8f.2 for <78582@debbugs.gnu.org>; Mon, 02 Jun 2025 07:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748874412; x=1749479212; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=G1Jr6nOVwxfrnm+t4wmpV3HeW2wNmrEolmtgE2lw9Uo=; b=II8DApNbX3eWqIDvKP8Y/0SUUmgodmuoVK34NkThoNgXb6BYCeJjJgjB7nRmm9dZzG F3f+EW1R/6lN4wwV605071gQQ+n5Zi7/Q+aGElSzNDY0I28mqJQMKcPEMbJvqpN6LTAK VI0CAv+kXSzWdbnCHc7OIrsgPfJXEJi1WN1OtDTo5nh+MS+z2Gy/bgMsLeGaqffmkD7V v7A3ruJ/UFzI27PZBf56hlZGVdYqqDhsmIgXajzTbmusFmWsbAjZJW/dpi5hLnkA1IhG XpLVLU9Ie/UQTEsWO1VnOWPRKgOwlUxyNNIKQH2Tgbq3XaTifOJuDVE07+xaBg9dAGyv H7pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748874412; x=1749479212; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=G1Jr6nOVwxfrnm+t4wmpV3HeW2wNmrEolmtgE2lw9Uo=; b=YZ41+o/HuEwbebBOMGl84iXpEnvIbjWcaYHQgNFiSrOL4LFQoT1xFK+XufjfBYgBrM wEqmXa+8VVjyJqCxWLw10dp7gkLqZKoXVwPX+gsQg18MloZPg3ohMlGa7hZYM6gKaTyZ fls4zQ1cfAPWY1Gvn8nrEkZrU/zscooWyJBepZRclh96xYpjUcauB+afDTI35K7AOeWm 2lYYdnTL1WRTzGBfgdFyuK+xZUdpupMQXnfY6XhE/F4HXz7EqaGsSIZChHrwGnvaIYcv k75kPUoewVVegrno0aFWNEJJDPrX0wXJpsn+3YASoJt6+8u2eqLofu2UwTtEUDt+h07V ULeg== X-Forwarded-Encrypted: i=1; AJvYcCWKzQ4gmLoovf3620xIqVUNbUlQipvUnHr764lP6R4kOzd/w8+idSR/48wrdKGXl95A/Z2hEQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyZAEQ3rasHBeYGXmELrmjHpgnQrRbDHWU0WTzXOYac/39Z+lx6 b/usmhD0CPAS7MOrvNn45FCO8IJfBfV7/XCqaoFehWjLZro1Or1V8gEdXZhobds+ X-Gm-Gg: ASbGncux89Wl5Go2kuPaY6Sfbwq78ns263V9w2h66nq+J9o2Ca1iKlIDBnuBYNiMimN U+nhXtNBKLWp1o28OYOk9XoiJ22i6ThkEl8p7lxQPnJul8b1rfLTzWWTwDhQ/KLwhEDTFVR385S TOTmieekvGZAUd8sEIiJ0doIvsqx2Al7gZSBUfRH70w1bW94IHnW3D5F1dZ0qjFwtpoiFRUk+5C trLuJgLU4pWIJVniUIX/XcmTdR3hYwLRresjBJu36Jq/8KI/GAA4ikh4zdbXhj7IT0zIBwqzvt2 Af/552yqRZEvAIaXEoFMf07QM9PKp0rGs8BfNc8= X-Google-Smtp-Source: AGHT+IE7r1PfSFqUXf9w1AlhbP/NJWaI9dxAZnsxAgwNtNo/RPwWW8CmGy7pqcbKV141IKhbcP9NEQ== X-Received: by 2002:a05:6000:1aca:b0:3a0:9dfc:da4 with SMTP id ffacd0b85a97d-3a4f89da7a9mr9433434f8f.42.1748874411410; Mon, 02 Jun 2025 07:26:51 -0700 (PDT) Received: from rltb ([2a01:e0a:3f3:fb51:4b75:bdfd:4670:efa2]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4f00a00d4sm15296344f8f.92.2025.06.02.07.26.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 07:26:51 -0700 (PDT) From: Robert Pluim To: Stefan Monnier Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> Date: Mon, 02 Jun 2025 16:26:50 +0200 Message-ID: <871ps2cj85.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: Gerd =?utf-8?Q?M=C3=B6llmann?= , murray.alex@gmail.com, Eli Zaretskii , luangruo@yahoo.com, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> On Mon, 02 Jun 2025 10:11:16 -0400, Stefan Monnier via "Bug reports f= or GNU Emacs, the Swiss army knife of text editors" = said: Stefan> Maybe we should try and work harder to make such reloading more= harmless Stefan> (e.g. replace the `define-key/global-set-key`s with functions w= hich do Stefan> nothing if the key is already bound?), but it's an issue that a= ffects Stefan> only those people who hack on the code of the very Emacs they're Stefan> running, so it's not super-high priority. At least for kmacro.el, any reason we can=CA=BCt put those `global-set-key's in bindings.el? Robert --=20 From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 11:09:09 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 15:09:09 +0000 Received: from localhost ([127.0.0.1]:52832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM6mj-0001vt-6J for submit@debbugs.gnu.org; Mon, 02 Jun 2025 11:09:09 -0400 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:55787) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uM6mg-0001vJ-8S for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 11:09:07 -0400 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-450caff6336so26600525e9.3 for <78582@debbugs.gnu.org>; Mon, 02 Jun 2025 08:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748876939; x=1749481739; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=24Bf+1jB2YS/Xc6Bk/cAVFmVjvbntR/qx8d+nf0+C0s=; b=TRA1ARfMgYkBF7MbusdDLyfnyVmpPyfD8bmbAC8MtOrEVIZlKmovAgD/Mzmrwppmse ceV4V6dWI4ASgk3q8t33kizfV+3PO2jZcvwbPiYYvTVNx5I3spSCRcxoQiBUbITRzIqe bJx1EbyOSdUSfoiDh5tM1ODC/cUE9Z6s8wpTEBh27xf50KpLYz3rAiRTJvmhv7bIxcDT wgqrxXyu4yZG19IsrzRvYMuFNReBIWJpbhKXAq6WMz9X0Qlpt1uw22VfjWaMkB1BVq0Q ZON/zmu2iS8rj5T413RbzctCt2k/+Ax8Cd4w72Y66vYk5SmUBQAb0Rg/FriQ0nBax1vm xcNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748876939; x=1749481739; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=24Bf+1jB2YS/Xc6Bk/cAVFmVjvbntR/qx8d+nf0+C0s=; b=nTyJ9EyftOeYOCq/RNjESmbtrZs2rGnH3XTHt+r0xbOeMv2Ih+PHLyIqL/trEc7x33 qTvSlNu8y1I5f5+f9zhvUTj71tap6VOGFMs2P+JsLVlX/PGVeEYjyQ/MvUsUxoI8+Hwx nwkmZgJQtb1gTV7pAqt7zTRwIYUSWFkUclyGDkWN6ZfzDO84A5eOnUmMZ4ZE8q4Hg9r0 echwGB1oVgfR7B9xg30pPZhoMvwAneKY13VtWxjChCA33qbbdAhlIMTtOD6nnhEicYcM wOOPXNn1PWeHiiP4g1jdSnxbV9SFfLg9Xostou4uAZi7061MXbGRF/RV473ewSFzZO1T zNTg== X-Forwarded-Encrypted: i=1; AJvYcCW6J6Sbbdeuk8UhB2Y1ouzwxISJu3Uc5NeRo85WFj5e+gu1wbjGUFDTjAQcM+6RG8FFu3Gi7A==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwdWlm9Aa4/GVrdwtjBY+GMB50c05t9/eI+4zuKf3vPDmTinbBP ptL0247gG6bW3/Y3EIGSnUeV0Hreuuq24BFw9qmc0F/I3pgiEmvUiWyVjggQBY6a X-Gm-Gg: ASbGncv1mNqBOiLuTER5faw2eo0IsK2enS4GCSXKVG45UXN3DLaFOiRX/T+JJqkuU08 WLJ6Ncb0nRFq09rftv0MBAeBpyhJNGxDNMalXGpN58VwOAGs0xfgwn8st8QyFlXDcbphRc0w1ij 2xU77akJCgpE/mbOecb4g2eWa4l+FGyWhm0ou3u64TU0KrnxjZHe3AJ/ykk4ZPmpr9r4fy0ZS7z JnJy2r5mz3gTJXfmvMawlBmxgsXjAOIXmH6J7JYQEkiUKAGATNB5ZjwwXvPN4H087wy4h/JkOrT kEfys6lUzk8lRgNk0k/CxqxF4MhPlDW45WUURbQbVIVvty8YAtocEwJk2xm6XwJcbnXFYN/6h8D gGS9cF/OOjEevc5H8Cnat/itVzIAdnc52Du940wpNNbvl9H4y8d0kplY= X-Google-Smtp-Source: AGHT+IG1c59J+1B+4suSFUfR13CcTfxv51mcXHCqO+9AqJK33aHTBodXs4CL2YGUJfzweJ+7vJzV9Q== X-Received: by 2002:a05:6000:4313:b0:3a3:6a9a:5ebf with SMTP id ffacd0b85a97d-3a4f89a8a5emr9662158f8f.20.1748876939233; Mon, 02 Jun 2025 08:08:59 -0700 (PDT) Received: from pro2 (p200300e0b72e350060f297ff9ecb4644.dip0.t-ipconnect.de. [2003:e0:b72e:3500:60f2:97ff:9ecb:4644]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4f0097205sm15335720f8f.79.2025.06.02.08.08.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 08:08:58 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> Date: Mon, 02 Jun 2025 17:08:57 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, Eli Zaretskii , 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >> doc.c: >> 310 static void >> 311 reread_doc_file (Lisp_Object file) >> 312 { >> 313 if (NILP (file)) >> 314 Fsnarf_documentation (Vdoc_file_name); >> 315 else >> 316 save_match_data_load (file, Qt, Qt, Qt, Qnil); >> 317 } >> >> Secondly, doc strings can point to loaddefs.el >> >> (function-documentation 'rectangle-mark-mode) >> =3D> ("loaddefs.elc" . 1059343) > > AFAICT the problem you describe is not specific to `loaddefs.el`. > The same thing can happen with any file that has a `global-set-key` call > at top-level. > > This reloading business is supposed to happen only if the in-memory > doc-string-reference is out-of-sync with the installed files, presumably > because you're running Emacs "in place" and the files have changed in > the mean time. > If that's indeed your situation, then "all is well": the problem you're > seeing is "on purpose". You can fix it by removing the above reloading > mechanism (in exchange for being unable to see the docstring in those > cases where the reloading would be needed). > Alas, the "supposed to happen only" is apparently not the case. The Emacs where I see this is an Emacs installation. In the case of macOS, this means "make install" has created an Emacs.app directory, a "bundle" as it is called on macOS, containing what a "normal" installation would contain. That Emacs.app I copied to the Desktop folder and start if from there. Too bad that I don't have a debug build so that I could see more. Why does it think in my case that it needs to reread_doc_file? > I tend to see this every once in a while where `C-x C-c` (which > I normally rebind to a less-drastic operation) gets redefined > to its default binding because `files.elc` gets reloaded. =F0=9F=99=82 > > Maybe we should try and work harder to make such reloading more harmless > (e.g. replace the `define-key/global-set-key`s with functions which do > nothing if the key is already bound?), but it's an issue that affects > only those people who hack on the code of the very Emacs they're > running, so it's not super-high priority. See above =F0=9F=A4=B7. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 11:38:14 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 15:38:14 +0000 Received: from localhost ([127.0.0.1]:53090 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM7Es-00047h-AO for submit@debbugs.gnu.org; Mon, 02 Jun 2025 11:38:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58608) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uM7Eq-00047I-9h for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 11:38:12 -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 ) id 1uM7Ek-0002Lx-9F; Mon, 02 Jun 2025 11:38:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=31UGzuUmyxFgCsongalsL+/w9WozTmCjMisDJ44XE6c=; b=MGE6bb6feN6FeW4e52LG NrxMClfdwgFQITuRG6U9sVRhFWH/lvLGA4V5dPfQjtfdwobM/eYgJLpVPqtE2irMJuTSVujqdBGDp 0W3/LTKYB7kVLHZ29l967tS7FLDmdy/F6+ZEJFKcDpVLLJ7IW2gkonJX9uLvenfAsf8wzT2+jv2/Z Sbsaabi7IHNKXUh3qHLWJg/YncBn/M6oUKCloXXoQsILUQa0NXcim2xhmZ4aoW63hCoSlJBBdw89F JR23BLOP02A7XZTAYGwsPKRj95M2mwcDc5XsuJSOvUiHwWN2ojW7hjvgyhFLHvDcNZEgmLW44fL0T 9SpBVW+1FfA2ig==; Date: Mon, 02 Jun 2025 18:38:03 +0300 Message-Id: <865xhep31g.fsf@gnu.org> From: Eli Zaretskii To: Robert Pluim In-Reply-To: <871ps2cj85.fsf@gmail.com> (message from Robert Pluim on Mon, 02 Jun 2025 16:26:50 +0200) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> <871ps2cj85.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: gerd.moellmann@gmail.com, murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Robert Pluim > Cc: Gerd Möllmann , > murray.alex@gmail.com, > luangruo@yahoo.com, Eli Zaretskii , 78582@debbugs.gnu.org > Date: Mon, 02 Jun 2025 16:26:50 +0200 > > >>>>> On Mon, 02 Jun 2025 10:11:16 -0400, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" said: > > Stefan> Maybe we should try and work harder to make such reloading more harmless > Stefan> (e.g. replace the `define-key/global-set-key`s with functions which do > Stefan> nothing if the key is already bound?), but it's an issue that affects > Stefan> only those people who hack on the code of the very Emacs they're > Stefan> running, so it's not super-high priority. > > At least for kmacro.el, any reason we canʼt put those > `global-set-key's in bindings.el? It would make the maintenance a tad harder, because the bindings will be in a different file. I'd say that benefits are not worth the downsides in this case. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 11:38:27 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 15:38:27 +0000 Received: from localhost ([127.0.0.1]:53096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM7F4-00048I-OR for submit@debbugs.gnu.org; Mon, 02 Jun 2025 11:38:27 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:9172) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uM7F2-00047t-Sc for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 11:38:25 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 50AAE1004AF; Mon, 2 Jun 2025 11:38:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1748878698; bh=ubR6lKn1pgkml11RSXWIGrIkgpWZigbTsn7nc4rP3Ys=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DDUI68znwsKwrr9/W7sPqbfVeZg9oHCKEgmF4rdWg3b0IP91Mdr+P+3eg+5gD5j6X p7IKQw+y9m5EA3Tt9p3kyHiGT0Bc3taDoIS2JVEuT4FYjdJdes8JKUVuq93Q/cYk/C KhOFS/kgbAxKFrMZ9wd+wDgVXBo4NOmoKoVpmoXs9gg6MKgd8lARRwX0imYFNbxgTe i/sTfJ+buimKL0h14MR6HzyEgTPiTrCG416+a5ili6kay0MwAB0cpnMfFUp7G16+fF /2VCqYDhiey9VsxnoTX54K7XvZqh5i5Rfhc54tuGkkBxZM689Q3NlI22ZAA6iTyFs8 QXQoRvA8htFbg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 48DD310006B; Mon, 2 Jun 2025 11:38:18 -0400 (EDT) Received: from alfajor (unknown [104.247.225.139]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F010C120504; Mon, 2 Jun 2025 11:38:17 -0400 (EDT) From: Stefan Monnier To: Gerd =?windows-1252?Q?M=F6llmann?= Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: Message-ID: References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> Date: Mon, 02 Jun 2025 11:38:17 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.340 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, Eli Zaretskii , 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Alas, the "supposed to happen only" is apparently not the case. The > Emacs where I see this is an Emacs installation. In the case of macOS, > this means "make install" has created an Emacs.app directory, a "bundle" > as it is called on macOS, containing what a "normal" installation would > contain. That Emacs.app I copied to the Desktop folder and start if from > there. > > Too bad that I don't have a debug build so that I could see more. > Why does it think in my case that it needs to reread_doc_file? if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc)))) { Lisp_Object tem = get_doc_string (doc, 0); if (NILP (tem) && try_reload) { /* The file is newer, we need to reset the pointers. */ reread_doc_file (Fcar_safe (doc)); try_reload = false; goto retry; } doc = tem; } so it's because `get_doc_string` returned nil. Usually this is because the doc reference points to a place that "doesn't look right" (is not immediately preceded by `#@NNN`). So maybe check the raw doc-string reference for `rectangle-mark-mode`: (nth 2 (symbol-function 'rectangle-mark-mode)) gives me ("loaddefs.elc" . 1044279). Then go look at loaddefs.elc to see if that byte position points to a docstring? Or maybe the problem is somewhere in our handling of preloaded files (i.e. those where the doc string reference uses a relative file name as above) where it ends up looking in the wrong directory? Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 12:56:09 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 16:56:10 +0000 Received: from localhost ([127.0.0.1]:53778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM8SH-0001sJ-Ih for submit@debbugs.gnu.org; Mon, 02 Jun 2025 12:56:09 -0400 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:51627) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uM8SE-0001rI-V1 for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 12:56:07 -0400 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-442e9c00bf4so29946805e9.3 for <78582@debbugs.gnu.org>; Mon, 02 Jun 2025 09:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748883360; x=1749488160; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=hqMlyAe+b+rrtujvUYRiJKZnXy4x1qxsLUMI5wkBLm0=; b=dxHUnwI6VX9mAZXg+J+bl3whlgNINKbuRk+Gi5LcqQnohKHXkGHASuOXGnIiHhN2eT Gq5XeA1bjGJ9gFpB94Q3FGAX6M1GRdHr0q85vKEyrntif2KitwABnuQ/D2gtpK4a0+xx HmaIix1Wr+G7xJA4hxIl+08BXQVzGNw1HyZ2tY8I5VHzn3P41f7J9wc9EGSaXCBPnMfj ryTlYhmEGaPfzLgPIaYA9NqJhF6zIgFN7Sl4BrLrX5+uzv2yuwRnl8ykIbYYw1OW7oJN wOzbtSjiPYQXAvt1V8mIZF2yFxMC2cB/zVjD64j2IH4WwSX4vHtc+ysnVcn+DhXdop87 OI9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748883360; x=1749488160; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hqMlyAe+b+rrtujvUYRiJKZnXy4x1qxsLUMI5wkBLm0=; b=PyUmdhc9I7U9jBwh0sxK2TJ3m9LQm6ZvXRohjKnyilw9Q0PIvtiiAQnAJh9faj1z5n IUk/mMrLgNeTNzgRECl4BIYG4cK7u8uF0vgzLxE3Je965Zwpvr1Ll5NypRklhhwSPeHg 4nuwjmLMCJC/Qltc6LS3xlmuAH7jUQnhbzxT6LLLKAep/hNICTvBT1G4aIlQuYUoXAH0 3Uq2AlhBJuvDpXy6yXSayK1qW5mwURSZv+xFxa+g99BZ82CLv2j3zmlMbUVm+k+JpRSc PzxNW6eaCocQ85JKbDXcL5YRt7bO3YoKCw8iKrU3bc+SVpocXuT7tz1zvSgXq0KMwIOC S5IQ== X-Forwarded-Encrypted: i=1; AJvYcCXYLYzyTCxMu13q8S3IQfwdTX7Q9QWy7D5PAM6YZLVAWYs6uvDsjF2LMSOZC5t6Wz3ea0ldbw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzvUH/1JB4O8D8uEjsRtKNLfe3yxCQ7Pi/+oTmOqQ1LEG9Kwots VXJN+iLfYaxwA0DCxTwLcbFI8GPu90BGm1MM+oTzVNhgDYVX8JjoI2VV6sJ6wvL9 X-Gm-Gg: ASbGncvPGrkNjrMlqhTKLNrCyeZzx/90QGyx+TDtcW+Tj8eMaxIa5BCwByILSN01kQv iFVvslHJdxj+BY9gyR79Dr2P3orxYUbgK03Dxe4PCRbcHIKetluk4zzB2U3Z5hRgOtRvxG1w7sB EBbTb02u8emZFPMKx7TJzVPhnZxZ9qaB3v/NCrAYNGY1501c3VO68KmNWazcO7d1Nx03+JSvYP+ dPFwjIfhp2rZXkrnqkbhv/DYzNMTPO50VC9a2Jc/2WKfmdc39ZfupTK3IRWzgMfrbpzY6I54MTx fyetQyTLSW8Z8aTc3x1AQ31wsKJvuh2FMtrbYIrim4lCiRwdZN3fdmVhGfoK+SsxrDrOmkceg3W ao5w0kDhiaLOa48SsAg8qLPy71txLXdp3H2ZBO0rgtXX5peNVRVI9Uus= X-Google-Smtp-Source: AGHT+IGowfBzAoaDwEbR3G3Y0K1Ec3Fu/PMzHcSAeJ0APpJYdmbBDvEB4CKm00U+049EKuBLuY49VA== X-Received: by 2002:a05:600c:4f50:b0:43c:efed:732c with SMTP id 5b1f17b1804b1-450d8876ce6mr85557565e9.28.1748883360384; Mon, 02 Jun 2025 09:56:00 -0700 (PDT) Received: from pro2 (p200300e0b72e350060f297ff9ecb4644.dip0.t-ipconnect.de. [2003:e0:b72e:3500:60f2:97ff:9ecb:4644]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-450d7f9efa3sm127677955e9.9.2025.06.02.09.55.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 09:55:59 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> Date: Mon, 02 Jun 2025 18:55:58 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, Eli Zaretskii , 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >> Alas, the "supposed to happen only" is apparently not the case. The >> Emacs where I see this is an Emacs installation. In the case of macOS, >> this means "make install" has created an Emacs.app directory, a "bundle" >> as it is called on macOS, containing what a "normal" installation would >> contain. That Emacs.app I copied to the Desktop folder and start if from >> there. >> >> Too bad that I don't have a debug build so that I could see more. >> Why does it think in my case that it needs to reread_doc_file? > > if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc)))) > { > Lisp_Object tem = get_doc_string (doc, 0); > if (NILP (tem) && try_reload) > { > /* The file is newer, we need to reset the pointers. */ > reread_doc_file (Fcar_safe (doc)); > try_reload = false; > goto retry; > } > doc = tem; > } > > so it's because `get_doc_string` returned nil. > Usually this is because the doc reference points to a place that > "doesn't look right" (is not immediately preceded by `#@NNN`). > > So maybe check the raw doc-string reference for `rectangle-mark-mode`: > > (nth 2 (symbol-function 'rectangle-mark-mode)) > > gives me ("loaddefs.elc" . 1044279). That's a good idea. On my Emacs in question, after a fresh start ELISP> (nth 2 (symbol-function 'rectangle-mark-mode)) ("loaddefs.elc" . 1059364) ELISP> (format "%x" 1059364) "102a24" > Then go look at loaddefs.elc to see if that byte position points to > a docstring? In hexl 2866 6e20 5354 4152 5420 454e 4420 5354 (fn START END ST 001029f0: 4152 542d 4154 2026 6f70 7469 6f6e 616c ART-AT &optional 00102a00: 2046 4f52 4d41 5429 1f23 4037 3539 2054 FORMAT).#@759 T 00102a10: 6f67 676c 6520 7468 6520 7265 6769 6f6e oggle the region 00102a20: 2061 7320 7265 6374 616e 6775 6c61 722e as rectangular. 00102a30: 0a0a 4163 7469 7661 7465 7320 7468 6520 ..Activates the 00102a40: 7265 6769 6f6e 2069 6620 6974 2773 2069 region if it's i which is pretty far from the #@759. So the question is how gets the wrong offset into the function-documentation, or maybe how gets loaddefs.elc modified. Weird. > Or maybe the problem is somewhere in our handling of preloaded files > (i.e. those where the doc string reference uses a relative file name as > above) where it ends up looking in the wrong directory? Could be, but the directories in question at least look okay. ELISP> lisp-directory "/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/" ELISP> doc-directory "/Users/gerd/Desktop/Emacs.app/Contents/Resources/etc/" From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 13:53:17 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 17:53:17 +0000 Received: from localhost ([127.0.0.1]:54335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uM9LY-0006MU-9B for submit@debbugs.gnu.org; Mon, 02 Jun 2025 13:53:17 -0400 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:49405) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uM9LV-0006Lz-Oi for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 13:53:14 -0400 Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-3a3673e12c4so3148970f8f.2 for <78582@debbugs.gnu.org>; Mon, 02 Jun 2025 10:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748886787; x=1749491587; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=XSL3Ltvdt8uIfi9Hmt50ZG4ZoiGuallQcTycPXmwKJg=; b=SvlwT0peHR+V/147/T3DpN2LNkrIClIo+lwwb4bTYnP6yy5VfrlPigxdaFgV79lGVD B5cLyL32AymyXcyjQQrzFA53hhhB8U7CuyLEOPCnkod0UczuZUPJap+C6sHAdN0yD+Ke n/310N7Lo8GXPmzS0nM5uo52aTTIqqilY52zakfC3vC+3Qk1ECxDAtzxwjRfzRH0Buqc IsjHJ/wYJz8BWHak5boCW7EPivcOA10VTPy5CiZZnNHuxjgHe234sr6BXxrQG4TYIw+X Lh8lTOKh8V6ZnzJ7L4h95LkmLJ0AejGXBsDlzEAgI5+JLQ+Pdg48b7QqWzV7FTgNcNgg CNZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748886787; x=1749491587; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=XSL3Ltvdt8uIfi9Hmt50ZG4ZoiGuallQcTycPXmwKJg=; b=kogeT1XHKRpJuQt4qj0dL4g10qcbQlyhrPSnN1yCFIyqgQx7cvOl1mJxRTsekaYY9n +zqtVeXemfRGWeKTQY94w9PqPCtgnmjzXfvbnrWM6TZvWk3j4UnclLMfFluH4+W6NHF9 pXanvzI98sQQhmGL/k8er7dCuHXRI8CH3suWeP5gIaVBtT5lTnjBV9/A8US8m2wSCj9W fHYDxsgOucm1sZe3XfB8E98/U9JH3a7tM5awTX1FFn0KFNrt/z5GSiDLRkFp69ED94jb 7I/8ZRJVJBYg0qLOGyrSg2Z97vRpSTm4Rv5bsh1pnQbCHFAhejhxFZAT159M1oawvVQO lQew== X-Forwarded-Encrypted: i=1; AJvYcCXWHu0npcPn6Ha47g9U2stPBW8DwgMi+Zcsi34wcJPQzsGnpRQwd/rQ4qWQUxwWjuGxHz9Asg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyXw+WmR6p4d4I6xeomKavjDIPoq34Yf4u4wk5JVaK57h2raTnR e6GNVqI4r915mrKBHXNR1lOejoBlGaeO1X/NkgtODyViZ7bC3zu0RvepVdSwzB3J X-Gm-Gg: ASbGnctlxqLsgofID/rE5+bFNJdPNYk3n7f24DvI6ThRqHqqXNYqacKaXPtnOmDwcFw YtfO3plV48wYutwA7bSe9lDbDDA5K1yvCXqJ23fbe+5Eb/4tbTWXbs89dyhIPs6EuSlag4by7jp UT9G6gCxtJKhsGKsNQUDimUQeTEaqhXZcuzkJfVfxJSk+kzKRiY7Qwrn1MjeHoKUtY+FfLBwb1w rsRiadFzDJIg8MYy/Ea4HCxAPoKMlJFZICcdI2L0UP0ix5HL2wp6Juh6CkjklEt8I19UiCYDKBM cO2BV5lyah+FfXtBgd5/91BZpcTZQyoz/TKDg6k3nVSMFwqAZctDjMuQF7xfc5cwRof2gocchjz 3Vn/QQKnYB6V07rB/+GPkxKo34piDGtgOsOb7IH5xAk4woJuAjAn4oWAbQdgK+dYOBA== X-Google-Smtp-Source: AGHT+IFLXjYglxDAut4a6/O1xkV/2WJcs2hXrIWe4Cy5wkhPwH7Szc7/0XpXacXRL9VPjrfICzkYbQ== X-Received: by 2002:a05:6000:220b:b0:3a4:dd8e:e16b with SMTP id ffacd0b85a97d-3a4f7a4d416mr11271247f8f.20.1748886787263; Mon, 02 Jun 2025 10:53:07 -0700 (PDT) Received: from pro2 (p200300e0b72e350060f297ff9ecb4644.dip0.t-ipconnect.de. [2003:e0:b72e:3500:60f2:97ff:9ecb:4644]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe5b92bsm15405325f8f.9.2025.06.02.10.53.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 10:53:06 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> Date: Mon, 02 Jun 2025 19:53:05 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, Eli Zaretskii , 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Stefan Monnier writes: > >>> Alas, the "supposed to happen only" is apparently not the case. The >>> Emacs where I see this is an Emacs installation. In the case of macOS, >>> this means "make install" has created an Emacs.app directory, a "bundle" >>> as it is called on macOS, containing what a "normal" installation would >>> contain. That Emacs.app I copied to the Desktop folder and start if from >>> there. >>> >>> Too bad that I don't have a debug build so that I could see more. >>> Why does it think in my case that it needs to reread_doc_file? >> >> if (FIXNUMP (doc) || (CONSP (doc) && FIXNUMP (XCDR (doc)))) >> { >> Lisp_Object tem =3D get_doc_string (doc, 0); >> if (NILP (tem) && try_reload) >> { >> /* The file is newer, we need to reset the pointers. */ >> reread_doc_file (Fcar_safe (doc)); >> try_reload =3D false; >> goto retry; >> } >> doc =3D tem; >> } >> >> so it's because `get_doc_string` returned nil. >> Usually this is because the doc reference points to a place that >> "doesn't look right" (is not immediately preceded by `#@NNN`). >> >> So maybe check the raw doc-string reference for `rectangle-mark-mode`: >> >> (nth 2 (symbol-function 'rectangle-mark-mode)) >> >> gives me ("loaddefs.elc" . 1044279). > > That's a good idea. On my Emacs in question, after a fresh start > > ELISP> (nth 2 (symbol-function 'rectangle-mark-mode)) > ("loaddefs.elc" . 1059364) > > ELISP> (format "%x" 1059364) > "102a24" > >> Then go look at loaddefs.elc to see if that byte position points to >> a docstring? > > In hexl > > 2866 6e20 5354 4152 5420 454e 4420 5354 (fn START END ST > 001029f0: 4152 542d 4154 2026 6f70 7469 6f6e 616c ART-AT &optional > 00102a00: 2046 4f52 4d41 5429 1f23 4037 3539 2054 FORMAT).#@759 T > 00102a10: 6f67 676c 6520 7468 6520 7265 6769 6f6e oggle the region > 00102a20: 2061 7320 7265 6374 616e 6775 6c61 722e as rectangular. > 00102a30: 0a0a 4163 7469 7661 7465 7320 7468 6520 ..Activates the=20 > 00102a40: 7265 6769 6f6e 2069 6620 6974 2773 2069 region if it's i > > which is pretty far from the #@759. So the question is how gets the > wrong offset into the function-documentation, or maybe how gets > loaddefs.elc modified. Weird. > >> Or maybe the problem is somewhere in our handling of preloaded files >> (i.e. those where the doc string reference uses a relative file name as >> above) where it ends up looking in the wrong directory? > > Could be, but the directories in question at least look okay. > > ELISP> lisp-directory > "/Users/gerd/Desktop/Emacs.app/Contents/Resources/lisp/" > > ELISP> doc-directory > "/Users/gerd/Desktop/Emacs.app/Contents/Resources/etc/" And in another Emacs.app installation I did just now, the offset looks right. ELISP> (function-documentation 'rectangle-mark-mode) ("loaddefs.elc" . 1059343) ELISP> (format "%x" 1059343) "102a0f" 001029f0: 4152 542d 4154 2026 6f70 7469 6f6e 616c ART-AT &optional 00102a00: 2046 4f52 4d41 5429 1f23 4037 3539 2054 FORMAT).#@759 T 00102a10: 6f67 676c 6520 7468 6520 7265 6769 6f6e oggle the region And the problem doesn't occur then, of course. Nice. And hard to find. I guess I'll go and move the bindings to bindings.el in my Emacs instead of wasting my time :-). From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 14:56:40 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 18:56:40 +0000 Received: from localhost ([127.0.0.1]:54909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uMAKt-0002vt-Th for submit@debbugs.gnu.org; Mon, 02 Jun 2025 14:56:40 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21711) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uMAKr-0002v5-Cg for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 14:56:37 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DB5A210013E; Mon, 2 Jun 2025 14:56:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1748890591; bh=Tz4BYadEkjxltVi8SzBt0Dp7AlbPUR2StFa7BVwy5+c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CQAOHYEUZGCZeh5PFEdfAwdyxbzIzUQwj2tUJAYIFnXNiSUZs+M6pqNBuiIp1RjLA NpTquVYL4VEuUxo0Jq35afgCaVJo4AdmxBxZGdYLYwUcNDt8q0ZPiKOEd0h3MC02z2 iFzxCYUSw+SAb74Wnwa1sXquMzT5wRNF3NTUH0Hnp/Ib0iPZd8vqzqC0Op5uBZr9W2 eY7griPtOZTPdRxM/nr2vaj8avQL3+C74/e1gZ0mlB7GZJPcKTEtcHAqluLzjawrcq 3d6eFIW6UMs6aebfdS9dSuvdbB9EA35jCsfC6c4IEoMdVNlFuXV78OQOPUwwch3DIM aBQtZ6/9DnF+w== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id EE1E410006B; Mon, 2 Jun 2025 14:56:30 -0400 (EDT) Received: from alfajor (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BB980120444; Mon, 2 Jun 2025 14:56:30 -0400 (EDT) From: Stefan Monnier To: Gerd =?windows-1252?Q?M=F6llmann?= Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: Message-ID: References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> Date: Mon, 02 Jun 2025 14:56:30 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.272 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, Eli Zaretskii , 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > which is pretty far from the #@759. So the question is how gets the > wrong offset into the function-documentation, or maybe how gets > loaddefs.elc modified. Weird. Looks like something happened in the build which caused the `loaddefs.el` to be updated "too late", i.e. after the last dump. I think I've seen this happen but I have no idea what circumstances can trigger it. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 02 15:23:15 2025 Received: (at 78582) by debbugs.gnu.org; 2 Jun 2025 19:23:15 +0000 Received: from localhost ([127.0.0.1]:55136 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uMAkc-0004xR-Sp for submit@debbugs.gnu.org; Mon, 02 Jun 2025 15:23:15 -0400 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:47473) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uMAkW-0004wm-Nd for 78582@debbugs.gnu.org; Mon, 02 Jun 2025 15:23:12 -0400 Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-3a361b8a664so4644446f8f.3 for <78582@debbugs.gnu.org>; Mon, 02 Jun 2025 12:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748892182; x=1749496982; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=XzqdEKRng3Pdmy/jhpO/1HGQn5LTYDWlz9G8rPACoJo=; b=Shjz0k/3fK9ADusVj8ZDqEP+DLU+aWphxMMRS1DHdg5mWcoKiIfcrbsJxBieIu07Gj 8M0HFglt2B5WAWAjYlgvhLWf6VafaqlshYiDW+gz7pqDXhOUV9q3PPlH1sfljjvZ6vPS FfhDCvS9NtOCq0y5GnaAmv6iO2g/j8dODDWSadQtWO4CfhsO7Z96qHD7uyx06qWRsiqy LXQTKstp7BrPrf2Q+HoS9hT85jTvs8bpiNu6NEe+wEp/ADadA2PmdTC9ZqppNR4/Qf2P TyqeQu02Hvm0k66hyzbCT5KFxyUncvEvZYRp5YSDNNou1ShGba7WRuBg8tYTVilf0ikE 154A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748892182; x=1749496982; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=XzqdEKRng3Pdmy/jhpO/1HGQn5LTYDWlz9G8rPACoJo=; b=obn8bCN5TkdspL9UUGXRUL34TyZu7/H+8BcoN3uA9m4W8tbgvLV2+4Mml9D3e1hMRV wfs9gSPsThZNFmwHyt01Pn77jOJfeQm05n8PIZOZju2DdtQQfrmaqxJkyQx6icdmr8w0 f8ytKk6o6wsyzwQaSqfsRRZaCICtqtVJoDGMHkmaRwzliusPQTzGvtyMerUD++FSnBbk Xj8Bbl3Ji8D6P9pXZPqgzut/qf+iL1wDYJofGkMe3tq6cjFQK99SovhceCJYhAGvXxe5 BJbkOSOpxAl8/wTsfNE6MB2B2eDiAq37pxn+hTI374bV+X3o2X2afIBB9Aj1RXY4ilaY 7dvw== X-Forwarded-Encrypted: i=1; AJvYcCUuLsCzEFpHiN/CFB34O89GjBGgCp5lydp/aY7oYOw9h4rNParxZ1+advSflJ8QoyDoIQm9iA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwBaun/oMvwdWNNMjvIasWq+B2o0Kqu41YQ6S0+bqgcu+5rZjqu 5m/gsTg1aXnabJa5rapA6rJn+eml4sV4X82eniLStm5qvN2cNhw5YMO2Ob4n26Hb X-Gm-Gg: ASbGncsLRbCXc7itCIoIgeOsx/4ODGXgc5sdydsap8bDbt00YKAS7oY8zNU0KH5js6y axmbvAl3KionER8mo8Hh0VKV4wBHpg1I31WnWc8tleWr73B85tRN0F+6pxhBRJ4i4WwkLE9mXb0 gBfK6cQtYguPg6V/6z/BgAXSCKsAW10b6CRPOf63w4bpt8/o1wTN+b1/I7JCpGMyCREa6CHnAzY Y+1HvtqBYCsp5/o1dmU5ohgn/wLtB6mm8qPzKovfhQzJzHJ1FeoIkSVqLao6XdhaC34N88QA0vT UNuol2QBCZwY4wn54nSCAeyDzB6UpMOPN1ff3uP3DjL9e5nHsqdHOc8bO919AE2qjdJwKYMNCq7 /AGypzKXK4AAKmXyX+CIPDQfXyFUfIV6nfcEFHlRFI3y0tzsoCTqYyuM= X-Google-Smtp-Source: AGHT+IHJGAxqBtcEnN9iQts8s0y3jD+fuU4Alcx8N2G8IVkjeF7iH1ecAwuId/tN3JKrMKzAocnsmw== X-Received: by 2002:a5d:64ed:0:b0:3a4:e8c8:fb9e with SMTP id ffacd0b85a97d-3a4f7aaf9d5mr10560600f8f.49.1748892182188; Mon, 02 Jun 2025 12:23:02 -0700 (PDT) Received: from pro2 (p200300e0b72e350060f297ff9ecb4644.dip0.t-ipconnect.de. [2003:e0:b72e:3500:60f2:97ff:9ecb:4644]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4f0097813sm16095614f8f.72.2025.06.02.12.23.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Jun 2025 12:23:01 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> Date: Mon, 02 Jun 2025 21:23:00 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, Eli Zaretskii , 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >> which is pretty far from the #@759. So the question is how gets the >> wrong offset into the function-documentation, or maybe how gets >> loaddefs.elc modified. Weird. > > Looks like something happened in the build which caused the > `loaddefs.el` to be updated "too late", i.e. after the last dump. > I think I've seen this happen but I have no idea what circumstances can > trigger it. > Yeah, I guess that's the most likely possibility. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 03 07:39:51 2025 Received: (at 78582) by debbugs.gnu.org; 3 Jun 2025 11:39:52 +0000 Received: from localhost ([127.0.0.1]:32800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uMPzg-00053V-Tg for submit@debbugs.gnu.org; Tue, 03 Jun 2025 07:39:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45120) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uMPzd-00052B-Ru for 78582@debbugs.gnu.org; Tue, 03 Jun 2025 07:39:46 -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 ) id 1uMPzX-00072V-FT; Tue, 03 Jun 2025 07:39:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=3Q39vWZ3/xE2vZmdN4QPMyrONZjga9y/oRAKScSbkgU=; b=kpvJxClYcjjzLKOY/l6o Ibbbf7740LBgsy8bCtOqW/v3pxNZx/5hIRJkJpljr6USDjabCdz4vDuENkVwsx3TJFPMOktkJdwSt BMyQB1I1WRrjCiY7IbMgPXKDtZyIDijb+bC7G9eVY8e+hAbtU8vkDvS/FcanRWGL93FZmZ/sXrFRj Q4VLJdbXi3Fnk3uP8oc0r/94+WWgZxKSL8GGLqX+wAD7wMthPdOvd5H1YH407BVJjSRzqCJQ2HMa+ ue6GgbaTKWZI3eYXLy6fYHqkXHSlmlRnCHn/IikJ/HF5fLF0jUJkiZ+msTI5krVDGpskWPk0RbFcV vQGtnCXA1myCrQ==; Date: Tue, 03 Jun 2025 14:39:10 +0300 Message-Id: <86sekhnjfl.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Mon, 02 Jun 2025 21:23:00 +0200) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: Eli Zaretskii , murray.alex@gmail.com, > luangruo@yahoo.com, 78582@debbugs.gnu.org > Date: Mon, 02 Jun 2025 21:23:00 +0200 > > Stefan Monnier writes: > > >> which is pretty far from the #@759. So the question is how gets the > >> wrong offset into the function-documentation, or maybe how gets > >> loaddefs.elc modified. Weird. > > > > Looks like something happened in the build which caused the > > `loaddefs.el` to be updated "too late", i.e. after the last dump. > > I think I've seen this happen but I have no idea what circumstances can > > trigger it. > > > Yeah, I guess that's the most likely possibility. If that's the case, then saying "make" in the build tree should re-dump Emacs. Does it? (It also means we probably have a subtle bug in our Makefile rules, because this situation should not happen.) From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 03 08:05:38 2025 Received: (at 78582) by debbugs.gnu.org; 3 Jun 2025 12:05:38 +0000 Received: from localhost ([127.0.0.1]:32948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uMQOe-00008p-W7 for submit@debbugs.gnu.org; Tue, 03 Jun 2025 08:05:37 -0400 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:43353) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uMQOb-000053-2f for 78582@debbugs.gnu.org; Tue, 03 Jun 2025 08:05:34 -0400 Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3a4f72cba73so3028887f8f.1 for <78582@debbugs.gnu.org>; Tue, 03 Jun 2025 05:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748952326; x=1749557126; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0R9mbgqjvJGphFYL/kw9NfYg5oPmdwyipeVpWbFs500=; b=f9GH+9tAr1lMsIOLKTnI6yNOcY7IQdybAMcRKIzX2XQYVzSxD60k42dAe8+qLhPT7R /HG0CwD/hjkpjDsR+QMGUe/Mmvp9Y3iUtwr5CwViEV1KdNIE1fOPnu8P5f8M9kqg1ncF 1C7Hbt7U8Kc0O9Ar69JpwMJZTiq68BdU21Ihx2quIfGlkqBGrz2l+15CHYFLlOfTebFC swibuczfSZPvAZhacl6lN6BIuEP3agptuFIHZB9o4kUdeLAHH/UhOgFaY4EHWLQBGW4E aOz8gb6dt+sXq7DfjK4zTKtkroWfK5FguiqYGVYvF8F0fuRKyYGD8MrElT+SW9eNY0Kt AgNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748952326; x=1749557126; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0R9mbgqjvJGphFYL/kw9NfYg5oPmdwyipeVpWbFs500=; b=RngRaOOMPbmZj3B0ch7Vs3ve5uFCnLxMz05SHZkkmXvD2ycZT6uNIH8Y7ueh+KFXu4 D4lMyTIw9jwrCr9MmrqEQ3ZqwE0PEhdF8Ij6IuietDlFQhUfYyz5F+Feeuv+Un7YGVeF 8xLRXSKUomXpHt7uZUY1pPaA6FkZlX/PQhtiXb2SL2Koaxbamg2wFC3NaaAC5k4c2d0d WlQm4AXsMn8sjePYiv8SNxhLTh+IqTig3ZLNRlqAJOD8I0hDrOJBmFjR8XqPLkN2wRR9 v6GAxVpbTHfNJzenZSyLIkxTnqlzWmUYXNRz3nI4bCiJo4oTy/dUqhKvIp15wlyZgecr 3WUQ== X-Forwarded-Encrypted: i=1; AJvYcCUsjaYd4+HQ8HNv9khXmChCkxrMfE/xxWTt9i5Fg2JCDF5KSxNWn8E+WAUpGLfEE5TW2ohYyw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz5fvTF4wExOQTGXVTdKMtkc6wJk2FCLLtb/Sx1mYNVJMM2H8x6 rkZWTbv40o8ZhPbEBhhY6s58GJ8zHU/4ZASG9GvnUNcOJIQl5U3Hp4YhVDvMw4xi X-Gm-Gg: ASbGncux/8my2Ybv9iiHqvnez/QXpPFPjL7T0Q9Ec3fQZ3+4Vcx0E/IqdLxBkZadDbY FP9o5x2mFT3GkKGKfYfrabB8v/5PBlEhvKK0PsriQYLELN194RqLt/+N2yrBxD+Eo8E3dKJehHf eeRHw8W2qtprDygExgcGfFW0kG7Apubb+Nyfp9YSusCvVWXQBPytQcXRbtd+zOV1EXzsKF4pWVy laNqJGQWJ7JE/mKdWDnQkKK9hRNQdLTh6vgsstvwZhTYMpfb0lm1cWwwI7gFjyr6gg3XK2NxBuZ 5Xp9pUVynRGm/Z7yu46Bd0yJkOnTnedseuICdGbHnA/Y3/X19SbkBMAjEAzLhlDdkHCzMg7jDWR cNffIdTOc5UN/upFJYNs/WeprCFuhAMvL1Pi7d02/4ezlcjkzShF9yHd3kkWwK7sabQ== X-Google-Smtp-Source: AGHT+IGBgBbnGSaBNJEHfqiL8uic8T9Lyy/GLUy3OO/yra85hV4PFhYlGEii3yeFlioFzJy4DBJQmQ== X-Received: by 2002:a05:6000:2012:b0:3a4:eb0c:407a with SMTP id ffacd0b85a97d-3a514604807mr1798894f8f.28.1748952326069; Tue, 03 Jun 2025 05:05:26 -0700 (PDT) Received: from pro2 (p200300e0b7301c00751cfee0d8e398aa.dip0.t-ipconnect.de. [2003:e0:b730:1c00:751c:fee0:d8e3:98aa]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe5b87csm18343194f8f.12.2025.06.03.05.05.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Jun 2025 05:05:25 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: <86sekhnjfl.fsf@gnu.org> References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> <86sekhnjfl.fsf@gnu.org> Date: Tue, 03 Jun 2025 14:05:24 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: Eli Zaretskii , murray.alex@gmail.com, >> luangruo@yahoo.com, 78582@debbugs.gnu.org >> Date: Mon, 02 Jun 2025 21:23:00 +0200 >>=20 >> Stefan Monnier writes: >>=20 >> >> which is pretty far from the #@759. So the question is how gets the >> >> wrong offset into the function-documentation, or maybe how gets >> >> loaddefs.elc modified. Weird. >> > >> > Looks like something happened in the build which caused the >> > `loaddefs.el` to be updated "too late", i.e. after the last dump. >> > I think I've seen this happen but I have no idea what circumstances can >> > trigger it. >> > >> Yeah, I guess that's the most likely possibility. > > If that's the case, then saying "make" in the build tree should > re-dump Emacs. Does it? > > (It also means we probably have a subtle bug in our Makefile rules, > because this situation should not happen.) No longer reproducible, alas. I built that Emacs.app, copied it to the desktop, and proceeded with the repo independently of it, which included new builds. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 04 06:39:28 2025 Received: (at 78582) by debbugs.gnu.org; 4 Jun 2025 10:39:28 +0000 Received: from localhost ([127.0.0.1]:47694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uMlWq-0006Ql-Ev for submit@debbugs.gnu.org; Wed, 04 Jun 2025 06:39:28 -0400 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:47385) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uMlWn-0006QR-Px for 78582@debbugs.gnu.org; Wed, 04 Jun 2025 06:39:26 -0400 Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3a361b8a664so6417042f8f.3 for <78582@debbugs.gnu.org>; Wed, 04 Jun 2025 03:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749033559; x=1749638359; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Jyzr9EkA+6uCYzMDJ/8A9F2PXvuzW8jaWA2GrNFieT8=; b=UxqT8TTvNwYBg9duYlkI0hu6tw08oRkYw+DTD9UBmsPLK6Dp/aEl48P2Sw3bkqbXZL 1RXo+DUPAuubPWzVMV06ijyChl3mExV5umQRiYpyT32oNBxKMnpb0NZUzDUs7QW9BIKg +UWGnJkRcyjKSA6HeK5m7JrjzlM/7eJ2GOY5TpdhSUfDn7T/u4cMh7gkmpdxpmbmlpig mDw7vRyr3DXwTCIEe5P4Ek+twxkKPBUcnmA6ANMWPpjLiOkJPWuD9FhVZaLYhU322QTl 4zCnmSMlFxE6/IBiE9JQVgNLvdIk/J2Lu23EfPffsZnKHAC7vKn1zOoKfcGR6YCmYg3v JDsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749033559; x=1749638359; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Jyzr9EkA+6uCYzMDJ/8A9F2PXvuzW8jaWA2GrNFieT8=; b=cw1kJXBQ8SAVkJM+mGOoAsovpR0nE3xdG2oEfs4RmML/+I2ZKS70F4AJdBpFofRkXO BnVtK9vH19LjEHqbYhIO7w9S0qqm8/Ht8kgfWzL93pKUPn1HxFyRuteMPAyRf+/a2KO3 HBF9CmgDHOvNHteJ7pdmZ35wqth5S5r8AJigiwoPOlzgZvcZjvSg5MlP6I68NhyhkbZl 0eqYpQG/W66orcuDGoNQvw7Tt3bm6uKOGdz3qeFcogl5PDv9j+v0syEgEkNiNZsHZr2O ZHtwMY2k7uVHNfI9gPk1GwcCVJrsoUFwz9jFd+1V4zct+grJxuCd9PVbJafYur8V/x5w LM4w== X-Forwarded-Encrypted: i=1; AJvYcCVbARWm+3Zw75HhTMozVpld+KBEiod3i0fC17zN5Nz0ahI6BX8+HTVMY19xQmbXwbH/l1+suw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YykID3MzFPxxrA6QaGhjFZ6G5fFRxwkXNUaOnT9ZwTRfPXXopOH RJyCBP/A4se00krTWn9imuwyCkQ/Y+CadMB6R9DMxMwto3+Dd6+s6jzPOxgEpWpa X-Gm-Gg: ASbGnctjZWBxbP8B7RSmFbuI0U6W4mcxnn1KyjZN0Ebxus8MUdkhTL6japvbjMphEFr oK5vQeRX5YO0tfMzxq7xPRCyS2eI2It6JKp3koySQxxDOLbj+br//z3BheLyk9VneyUb0+07x7c Eiytk15CcRkCHguskXHlP+KrdkHhgt09tHnoh/pPllgiRwf/FC5T2JqkTC/SNPFfCLOfnYyO2qv kc00aJT8u39ILoi1DXOeKKgnSu8NQLHcee/ukncQBHA4FR8WXrQ3hhTjJjtXgSuZKgFAFptuPjq zaA7GNOQ+a9qY2xfHshiIfphLhXhOFfnilSaSBpR2RRTrsAm271l72RTB399qK8hyvxOmVtbFpx aF+xVLiil/VCBkhH+QxtYRT9l30HZDWaw+ZUtYFfN1fCebj/bMN/7qEs= X-Google-Smtp-Source: AGHT+IHJGTeozFuySCxWtwvhq9AEjzUjr9gWlOEsYPaIpIY+jd9y6JRBXWZ1A6UdHBuPUoYr4gNBdQ== X-Received: by 2002:a05:6000:310e:b0:3a4:ef00:a7b9 with SMTP id ffacd0b85a97d-3a51d8f5fe6mr1578143f8f.12.1749033559210; Wed, 04 Jun 2025 03:39:19 -0700 (PDT) Received: from pro2 (p200300e0b7064c00350c47d314d56a72.dip0.t-ipconnect.de. [2003:e0:b706:4c00:350c:47d3:14d5:6a72]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe758besm21488235f8f.51.2025.06.04.03.39.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Jun 2025 03:39:18 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> <86sekhnjfl.fsf@gnu.org> Date: Wed, 04 Jun 2025 12:39:17 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Eli Zaretskii writes: > >>> From: Gerd M=C3=B6llmann >>> Cc: Eli Zaretskii , murray.alex@gmail.com, >>> luangruo@yahoo.com, 78582@debbugs.gnu.org >>> Date: Mon, 02 Jun 2025 21:23:00 +0200 >>>=20 >>> Stefan Monnier writes: >>>=20 >>> >> which is pretty far from the #@759. So the question is how gets the >>> >> wrong offset into the function-documentation, or maybe how gets >>> >> loaddefs.elc modified. Weird. >>> > >>> > Looks like something happened in the build which caused the >>> > `loaddefs.el` to be updated "too late", i.e. after the last dump. >>> > I think I've seen this happen but I have no idea what circumstances c= an >>> > trigger it. >>> > >>> Yeah, I guess that's the most likely possibility. >> >> If that's the case, then saying "make" in the build tree should >> re-dump Emacs. Does it? >> >> (It also means we probably have a subtle bug in our Makefile rules, >> because this situation should not happen.) > > No longer reproducible, alas. I built that Emacs.app, copied it to the > desktop, and proceeded with the repo independently of it, which included > new builds. I tried if I could see something in the Makefiles, but to no avail. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 05 10:19:29 2025 Received: (at 78582) by debbugs.gnu.org; 5 Jun 2025 14:19:30 +0000 Received: from localhost ([127.0.0.1]:34872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uNBRH-0005TP-5V for submit@debbugs.gnu.org; Thu, 05 Jun 2025 10:19:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46214) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uNBRA-0005S2-LE for 78582@debbugs.gnu.org; Thu, 05 Jun 2025 10:19:23 -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 ) id 1uNBR4-0001EO-Sx; Thu, 05 Jun 2025 10:19:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=qaOijhBqg/EwCzVt44sptWy04cz+1B29SSolCPj7OPw=; b=mTO63xDRbFV22bDrYuAz AUtdgXANAZb7EeLyiYbGwnCwCq/gnpI0chAKPxRRwpyYaL+p/7EmnK2MDR5pJFcrU9wvUzIdcIMVz P2ho86nTe0rXtDOSSuKBc/qym+GRs2eqLcOmnhHhAfkORHZvctuOxBAc63mtTjXas8g3Nv15M935A YQ5jW+2WDr5hugl1CNxnF7Z6tHYiTddkDif5alezRgx97iIHoimuxELrIGWShs0XFYcuL0TfJTblA ruuKa2jbgGD5VlbUpTZMmLqvW0Nazvd4oWX6cYzeOAdozs0sC45/PKsChfQLoq3EHV7JbDII0vWz1 R/F3IcICWHkIVg==; Date: Thu, 05 Jun 2025 17:19:10 +0300 Message-Id: <86frgemftt.fsf@gnu.org> From: Eli Zaretskii To: Gerd =?utf-8?Q?M=C3=B6llmann?= In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Wed, 04 Jun 2025 12:39:17 +0200) Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> <86sekhnjfl.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Gerd Möllmann > Cc: monnier@iro.umontreal.ca, murray.alex@gmail.com, luangruo@yahoo.com, > 78582@debbugs.gnu.org > Date: Wed, 04 Jun 2025 12:39:17 +0200 > > Gerd Möllmann writes: > > > Eli Zaretskii writes: > > > >>> From: Gerd Möllmann > >>> Cc: Eli Zaretskii , murray.alex@gmail.com, > >>> luangruo@yahoo.com, 78582@debbugs.gnu.org > >>> Date: Mon, 02 Jun 2025 21:23:00 +0200 > >>> > >>> Stefan Monnier writes: > >>> > >>> >> which is pretty far from the #@759. So the question is how gets the > >>> >> wrong offset into the function-documentation, or maybe how gets > >>> >> loaddefs.elc modified. Weird. > >>> > > >>> > Looks like something happened in the build which caused the > >>> > `loaddefs.el` to be updated "too late", i.e. after the last dump. > >>> > I think I've seen this happen but I have no idea what circumstances can > >>> > trigger it. > >>> > > >>> Yeah, I guess that's the most likely possibility. > >> > >> If that's the case, then saying "make" in the build tree should > >> re-dump Emacs. Does it? > >> > >> (It also means we probably have a subtle bug in our Makefile rules, > >> because this situation should not happen.) > > > > No longer reproducible, alas. I built that Emacs.app, copied it to the > > desktop, and proceeded with the repo independently of it, which included > > new builds. > > I tried if I could see something in the Makefiles, but to no avail. I guess we need to wait for this to surface again. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 05 10:26:28 2025 Received: (at 78582) by debbugs.gnu.org; 5 Jun 2025 14:26:28 +0000 Received: from localhost ([127.0.0.1]:34948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uNBY3-00063E-K9 for submit@debbugs.gnu.org; Thu, 05 Jun 2025 10:26:28 -0400 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:48548) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uNBY0-00062q-3r for 78582@debbugs.gnu.org; Thu, 05 Jun 2025 10:26:25 -0400 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-450cfb6a794so6917465e9.1 for <78582@debbugs.gnu.org>; Thu, 05 Jun 2025 07:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749133577; x=1749738377; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0mv1jJjp+N+ShfpMuS/tr5Wa18ITzf0JNoJ8sQrQVL0=; b=hg3Vw2Oe5rO2OLxQ68PXgl36KSeeUJney6sIRFXH0Va9dHLToR5VZReeF1eqnWvcH7 ZdndiJW77OJjm6cYYTsYApvtdh9uegXkrBa6xr6A27Y9eTYm2sUBTKThdEyLKsY5kth1 Zp8DkmZmg2YDnWUhBh7/mGD1MnrS5TJC7lP7Q9AIOU+X0Pv+K3OD0iFbLcKwhlTxGiTG zW+wv1/VePmkSxwWeKR85bqtfxF4QfQaV+CIz5WHgGD4GvzBE7td+DUpfOTjNR0SXei0 SDhanczVTjrz3t7fpJurwmF9kdirvJdqbxIt7pamlG9MieWA9SbEo3wD4jcEI2Q44HJJ loTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749133577; x=1749738377; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0mv1jJjp+N+ShfpMuS/tr5Wa18ITzf0JNoJ8sQrQVL0=; b=me05YMRgdQtC/nE/wTH+dslTdpMirEwmolm3CzAU3naOpcPUmQ2pzN04Ff8eg++pcP SXQhfa+u4LFi5OcQQ3GkK4ywkwa/7F6sxBK7oJv0G/asyenbYhSFBZyZVtsuWfI6hqks 1Pbh/EWMLLCV/gGzi21iLu3iTdWb6Gi4sQe/D/y3osV+vJWjD7o7XoDe0+C1QV9Istwx EMAcfv+dwa7fdWoxn1By/xEVIeZePc5ux4C691DsDBlB0TroAJdRMtr7qSlakk7p7aGR 149LmWJBTzk0AW9r3rJHod+ucFNYsDPPLwIyqBFR2IUNQ9G5H4bozDm6u2Afj9yxNeWB UlvQ== X-Forwarded-Encrypted: i=1; AJvYcCWg2LwFpm4ho5YYD4JxpybuhI1xzjn5el44KkjBi/HEWbea+DwEFa2OkQiUao1aNQaM/fHYww==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzGbmxQ2Mjeb+k+Om/vJkf6u5X25qreLGx5xCVoeXHhjYbPaf/G SaTdB1uKSKzVoHpJmCqkG2nzkiP7v8sxE+oh1EmzjuXNHkpljPBbn5+wrrsa9Lph X-Gm-Gg: ASbGncucJcq67PL/epGlhy3rFvXJPb8ceS0QSFFsA+DQ7tPGU3RcML1yjSIxL1PM1ZD SzrUdxFeuB1tWnHqv5eTinz7uPhimhBEkqhlodBoq1/ys1U6pJ5DiftxMdQNc1Ujnxfv8Oep9Lg ZqIqGCrhZS7T4Tf0WRSEObx8ttPoIneIOirKbgOyfrj4catVO8QTMHcqLlxzyvsJcgYKCxPSTBQ /a38GsqefIZ1lT5yt5LF2FTsl+MOvkcF6kInPUDMUE4flp4bwSu2BvrvBdgEQuGrCgBJXxupJv7 3jj1jnfvEkcrpMzuHapi1xvAMZKBrw7rlAyiLXzN9Jte9OYEgHHTv8N3YgFU6OC9A25eUG6sV/c 7gCHNMkYai5H/NcnZovx7HzStNpb7wjXHUgfwMEyP2hjtk75N5S3uJA== X-Google-Smtp-Source: AGHT+IEWwOmsY/Z6sZJk98GXbb1v1x3gLh4rj8Vd9lfALyUgUTILj6x/MuAnqaqt0yUXoXXWYCV6xw== X-Received: by 2002:a05:600c:3b01:b0:450:d00d:d0 with SMTP id 5b1f17b1804b1-451f0b10b58mr61382545e9.19.1749133577354; Thu, 05 Jun 2025 07:26:17 -0700 (PDT) Received: from pro2 (p200300e0b7095600688e4fdf01bce601.dip0.t-ipconnect.de. [2003:e0:b709:5600:688e:4fdf:1bc:e601]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe5b96fsm24335697f8f.8.2025.06.05.07.26.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Jun 2025 07:26:16 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Eli Zaretskii Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings In-Reply-To: <86frgemftt.fsf@gnu.org> References: <86jz62xpu0.fsf@gnu.org> <86cybuxnna.fsf@gnu.org> <86ldqapphd.fsf@gnu.org> <86bjr6pck9.fsf@gnu.org> <86sekhnjfl.fsf@gnu.org> <86frgemftt.fsf@gnu.org> Date: Thu, 05 Jun 2025 16:26:16 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 78582 Cc: murray.alex@gmail.com, luangruo@yahoo.com, monnier@iro.umontreal.ca, 78582@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: monnier@iro.umontreal.ca, murray.alex@gmail.com, luangruo@yahoo.co= m, >> 78582@debbugs.gnu.org >> Date: Wed, 04 Jun 2025 12:39:17 +0200 >>=20 >> Gerd M=C3=B6llmann writes: >>=20 >> > Eli Zaretskii writes: >> > >> >>> From: Gerd M=C3=B6llmann >> >>> Cc: Eli Zaretskii , murray.alex@gmail.com, >> >>> luangruo@yahoo.com, 78582@debbugs.gnu.org >> >>> Date: Mon, 02 Jun 2025 21:23:00 +0200 >> >>>=20 >> >>> Stefan Monnier writes: >> >>>=20 >> >>> >> which is pretty far from the #@759. So the question is how gets t= he >> >>> >> wrong offset into the function-documentation, or maybe how gets >> >>> >> loaddefs.elc modified. Weird. >> >>> > >> >>> > Looks like something happened in the build which caused the >> >>> > `loaddefs.el` to be updated "too late", i.e. after the last dump. >> >>> > I think I've seen this happen but I have no idea what circumstance= s can >> >>> > trigger it. >> >>> > >> >>> Yeah, I guess that's the most likely possibility. >> >> >> >> If that's the case, then saying "make" in the build tree should >> >> re-dump Emacs. Does it? >> >> >> >> (It also means we probably have a subtle bug in our Makefile rules, >> >> because this situation should not happen.) >> > >> > No longer reproducible, alas. I built that Emacs.app, copied it to the >> > desktop, and proceeded with the repo independently of it, which includ= ed >> > new builds. >>=20 >> I tried if I could see something in the Makefiles, but to no avail. > > I guess we need to wait for this to surface again. Maybe the OP has some info, log files or something from the build he is using?