If you heavily customize your keyboard shortcuts, you’ll eventually hit this: one mapping silently breaks another.
It took me years to get my setup where I wanted it. My daily stack looks like this:
- GNOME
- Terminal (urxvt)
- tmux
- vim
That’s multiple layers, each with its own shortcuts, buffers, and behaviors — all stacked on top of each other. Copy/paste alone can come from different sources (vim, tmux, system clipboard, browser), and you need to stay in control of which layer you’re interacting with.
Everything works — until it doesn’t.
The Problem
At some point, I mapped my Super (Win) key to Hyper.
In GNOME, this lives here:
/org/gnome/desktop/input-sources/xkb-options
My setting looked like this:
['ctrl:nocaps', 'altwin:hyper_win']
This used to work fine. GNOME even allowed shortcuts like:
Hyper + S
But in newer GNOME versions (around 48), this breaks.
Symptom:
- Pressing shortcuts involving that key → nothing happens
- GNOME simply ignores the Hyper modifier
The Cause
GNOME no longer properly recognizes Hyper as a usable modifier for shortcuts.
So if you remap your Super key to Hyper, you effectively lose it as a shortcut key in GNOME.
The Fix
Remove the Hyper mapping and go back to default Super behavior:
gsettings set org.gnome.desktop.input-sources xkb-options "['ctrl:nocaps']"
The Fallout
This is the annoying part:
- All shortcuts previously defined as
Hyper+...are now broken - GNOME will recreate them as
Super+...instead - You have to remap them manually
Takeaway
Hyper might look like a clean “extra modifier” on paper — but in modern GNOME, it’s effectively dead.
If you rely on GNOME-level shortcuts:
- Stick with Super
- Avoid Hyper unless you fully control the entire input stack
Otherwise, you’ll end up debugging “why nothing happens” again in a few years.
Top comments (0)