Why can't I bind C-= and why does C-h k ignore C-=?

Is there something special about the key combination `C-=`? I tried to bind `C-=` to `er/expand-region` from the expand-region package but nothing happens when I press `C-=`. If I try `C-h k` `C-=` it's as if I hadn't pressed any key at all. The minibuffer prompts me to press some keys as if I hadn't pressed anything. For example a bare `text-mode` buffer `C-h k C-= C-p` `previous-line`. Further, if i try binding `C-S-=` the same situation - it's ignored. Yet binding `C-+` works so when I press `C-S-=` what is bound to `C-+` executes. As far as I can tell my OS (linux) window manager (xfce4 xf4wm) doesn't bind C-= to anything special. **Update:** Adding technical information below: --- **OS**: Arch Linux (fully up to date) **Desktop environment**: XFCE4 **Window Manage**: xfwm4 emacs-version: "29.0.50" (emacs-build-description): In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.17.6) of 2022-10-27 built on ------ Repository revision: b7e59b9e194ac287fe627ccb26159d2f6f04939b Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101004 System Description: Arch Linux Configured using: 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-modules --without-libotf --without-m17n-flt --without-gconf --enable-link-time-optimization --with-native-compilation --with-xinput2 --with-x-toolkit=gtk3 --without-xaw3d --with-sound=alsa --with-xwidgets --without-compress-install --with-json '--program-transform-name=s/\([ec]tags\)/\1.emacs/' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fuse-ld=gold -fuse-ld=gold' LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' #(" " 0 1 (fontified nil)) --- ### ~~Solution~~ ~~I changed my keyboard layout (using xfce4-keyboard-settings) and the problem resolved itself. Changing the layout back to its original value does not cause the issue to re-appear though so I have no idea what the underlying cause was, only that it's been cleared and is no longer causing problems.~~ --- # Re-appearance of the issue My solution **didn't** work. The problem has now re-appeared. Sometimes emacs (and xev) recognises C-= then other times it doesn't. I can't see **any** pattern or event or OS setting that would cause this to happen. It seems clear it's something occurring at the OS level but I have no idea how to track down the culprit.

FWIW, I have this: (global-set-key (kbd "C-=") 'text-scale-increase) and it works fine as does `C-h k C-=` \- so no, it's just you!! :-) Does `xev` help?

GUI or CLI ?

Thanks, at least that confirms it's my setup. Trying xev -event keyboard > xev-output-= **Pressing only = gives:** Outer window is 0x4e00001, inner window is 0x4e00002 KeymapNotify event, serial 24, synthetic NO, window 0x0, keys: 0 0 0 0 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyRelease event, serial 25, synthetic NO, window 0x4e00001, root 0x296, subw 0x0, time 249126831, (163,-9), root:(1034,432), state 0x10, keycode 36 (keysym 0xff0d, Return), same_screen YES, XLookupString gives 1 bytes: (0d) " " XFilterEvent returns: False KeyPress event, serial 28, synthetic NO, window 0x4e00001, root 0x296, subw 0x0, time 249128091, (163,-9), root:(1034,432), state 0x10, keycode 21 (keysym 0x3d, equal), same_screen YES, XLookupString gives 1 bytes: (3d) "=" XmbLookupString gives 1 bytes: (3d) "=" XFilterEvent returns: False KeyRelease event, serial 28, synthetic NO, window 0x4e00001, root 0x296, subw 0x0, time 249128140, (163,-9), root:(1034,432), state 0x10, keycode 21 (keysym 0x3d, equal), same_screen YES, XLookupString gives 1 bytes: (3d) "=" XFilterEvent returns: False ClientMessage event, serial 28, synthetic YES, window 0x4e00001, message_type 0x133 (WM_PROTOCOLS), format 32, message 0x131 (WM_DELETE_WINDOW) Then trying xev -event keyboard > xev-output-C-= **Pressing only C-= gives:** Outer window is 0x2a00001, inner window is 0x2a00002 KeymapNotify event, serial 24, synthetic NO, window 0x0, keys: 0 0 0 0 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyRelease event, serial 25, synthetic NO, window 0x2a00001, root 0x296, subw 0x0, time 250910449, (-494,621), root:(377,1062), state 0x10, keycode 36 (keysym 0xff0d, Return), same_screen YES, XLookupString gives 1 bytes: (0d) " " XFilterEvent returns: False KeymapNotify event, serial 26, synthetic NO, window 0x0, keys: 150 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeymapNotify event, serial 26, synthetic NO, window 0x0, keys: 150 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyPress event, serial 28, synthetic NO, window 0x2a00001, root 0x296, subw 0x0, time 250913779, (50,-9), root:(921,432), state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeymapNotify event, serial 28, synthetic NO, window 0x0, keys: 150 0 0 0 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyRelease event, serial 28, synthetic NO, window 0x2a00001, root 0x296, subw 0x0, time 250914701, (50,-9), root:(921,432), state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False ClientMessage event, serial 28, synthetic YES, window 0x2a00001, message_type 0x133 (WM_PROTOCOLS), format 32, message 0x131 (WM_DELETE_WINDOW) I don't really understand the output but it looks like the first is recognising `(keysym 0x3d, equal)` and the second isn't.

It's using the GUI. Interestingly running emacs -nw and then C-h k C-= I see in the minibuffer Describe the following key, mouse click or menu item: ESC [ I- I don't understand what that means.

If it's the GUI, what OS and Window Manager are you using? You're responses would seem to imply X Windows but there are still options from there. GTK, Lucid, Open Step, Gnome, KDE, Wayland... Each of these has a chance of hijacking events from the keyboard for it's own purpose. Understanding the stack of software between your keyboard and Emacs is necessary to answer your questions. Unfortunately, config issues are the toughest because you have to understand the config at each level of the software stack

Two potential options---however unlikely---are: - your operating system or window manager uses the input. These take precedence over emacs. - your keyboard has some form of ghosting issues for those keys, i.e., if one key is pressed another key cannot be registered. However, this should usually be the case for keys that are close to each other. On my laptop this is the case for Caps-Alt-2. To test this you could try a software keyboard and input the hotkey there.

I ran into this on Mac when I switched to Dvorak, the OS was intercepting `c-space` because that’s osx’ way of switching keyboard layouts. I had to rebind it for the OS and for emacs to get it back to normal