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

Previous Next

Full log

Message #32 received at 78582 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex Murray <murray.alex <at> gmail.com>
Cc: 78582 <at> debbugs.gnu.org
Subject: Re: bug#78582: 30.1; which-key-mode overwrites custom key bindings
Date: Tue, 27 May 2025 14:20:23 +0300

> From: Alex Murray <murray.alex <at> gmail.com>
> 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.

Previous Next

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