GNU bug report logs - #78582
30.1; which-key-mode overwrites custom key bindings

Previous Next

Full log

View this message in rfc822 format

From: Alex Murray <murray.alex <at> gmail.com>
To: eliz <at> gnu.org, 78582 <at> debbugs.gnu.org
Subject: bug#78582: 30.1; which-key-mode overwrites custom key bindings
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,
Alex

Previous Next

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