Use layout-independent universal clipboard shortcuts

[janhesters]

Problem

Universal copy and paste can send the wrong application shortcut when the XKB configuration contains Dvorak and QWERTY layouts.

With us(dvorak), us and QWERTY active:

• Super+C opened Brave Downloads because the app received Ctrl+J.
• Super+V opened the Codex command menu because the app received Ctrl+K.

Chromium and Electron translate the injected letter key through Dvorak. Removing the release timer did not fix the behavior.

Fix

Use clipboard chords without letter keys for every focused surface:

• Copy: Ctrl+Insert
• Paste: Shift+Insert
• Cut: Shift+Delete

Omarchy already used the Insert variants in terminals. These keys are present in each XKB layout, so the same bindings also work in Chromium, Electron, terminals, and focused layer-shell fields.

The press and release remain in one callback to avoid stuck synthetic key state.

Validation

• Verified copy in Brave and paste in Codex with the affected Dvorak/QWERTY configuration.
• bash test/shell.d/hyprland-default-config-test.sh
• Added regression checks for all three layout-independent chords.

The full suite reached and passed the focused Hyprland test. I stopped it later because a Quickshell runtime test disrupted the live shell session.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates the Hyprland “universal clipboard shortcuts” implementation to send key press/release within the same callback and adjusts the shell test to enforce the new behavior.

Changes:

• Send send_key_state "down" and "up" back-to-back in the same callback (remove hl.timer delay).
• Extend the default-config shell test to assert the presence of "up" and the absence of hl.timer in the binding implementation.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
test/shell.d/hyprland-default-config-test.sh	Adds assertions that the clipboard binding releases the injected key and doesn’t use hl.timer.
default/hypr/bindings/clipboard.lua	Removes the timer-based release and dispatches key down/up in the same callback; updates rationale comment.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

test/shell.d/hyprland-default-config-test.sh:115

• This check will fail even if hl.timer only appears in comments/docstrings, making the test brittle. Consider matching the actual function call pattern (e.g., hl.timer() and/or excluding comment lines (e.g., ignoring lines beginning with --) so the test only enforces executable code changes.

if grep -F 'hl.timer' "$ROOT/default/hypr/bindings/clipboard.lua" >/dev/null; then
  fail "universal clipboard shortcuts resolve press and release in the same keymap"
fi

test/shell.d/hyprland-default-config-test.sh:124

• These assertions depend on an exact string match, so harmless formatting changes (whitespace, line wrapping, different quote styles) will break the test. Consider using a regex that tolerates whitespace (e.g., grep -E with \\s*) while still anchoring on the key parts (SUPER + C and send_shortcut_once( with the expected args).

grep -F 'o.bind("SUPER + C", "Universal copy", send_shortcut_once("CTRL", "Insert"))' "$ROOT/default/hypr/bindings/clipboard.lua" >/dev/null ||
  fail "universal copy uses a layout-independent chord"
grep -F 'o.bind("SUPER + V", "Universal paste", send_shortcut_once("SHIFT", "Insert"))' "$ROOT/default/hypr/bindings/clipboard.lua" >/dev/null ||
  fail "universal paste uses a layout-independent chord"
grep -F 'o.bind("SUPER + X", "Universal cut", send_shortcut_once("SHIFT", "Delete"))' "$ROOT/default/hypr/bindings/clipboard.lua" >/dev/null ||
  fail "universal cut uses a layout-independent chord"

[ivantsukev]

There is a compatibility concern with making Shift+Delete the universal cut shortcut. In GNOME Files/Nautilus, selecting a file and pressing Shift+Delete requests permanent deletion, with a confirmation dialog. Mapping Super+X to that chord would change “cut” into a deletion action in this context.

Could we preserve Ctrl+X semantics for file selections, or leave the cut change out until application coverage establishes a safe replacement?

Two changes would also make this patch easier to assess:

1. Evaluate the release-timer removal separately unless it is required for this fix. If it remains, include a reproduction and evidence that repeated shortcuts leave no stuck keys or modifiers.
2. Add behavioral coverage alongside the source checks: verify clipboard contents and text changes in Chromium/Electron and GTK, terminal paste, and file-manager copy/paste/cut using disposable files. Exact-string assertions cannot establish those outcomes.

I confirmed that a separate local keycode override fixes Super+C/V/X in both English and Bulgarian, but I have not tested this PR’s Insert/Delete approach.

Linking this proposal with #7375 and documenting the compatibility tradeoffs would help consolidate the overlapping work.

The Nautilus behavior referenced in the second comment is documented in GNOME Help
(https://help.gnome.org/gnome-help/files-delete.html).

[omarchybot]

Thanks for tracking this down, @janhesters — the Dvorak-first/QWERTY-active case is real. Hyprland resolves a named key like C against the active layout but delivers it with the first layout's group, so QWERTY C (keycode 54) arrives in Chromium as Dvorak J.

This was reviewed from source against current quattro and compared with #13007, which fixes the same mismatch a different way. Nothing was run on a worker, because only one of two competing fixes should be verified. #13007 resolves each letter against the primary configured layout and injects the resulting keycode, so it covers this exact scenario (C → code 31, V → code 60 on Dvorak) as well as the non-Latin "key not found" failure in #12570 and #7371.

What weighs against this approach as it stands:

• Super+X → Shift+Delete is permanent delete in GNOME Files rather than cut, as @ivantsukev pointed out.
• Ctrl+Insert/Shift+Insert are not universal aliases for copy and paste. In several terminals, Kitty's defaults for one, Shift+Insert pastes the primary selection rather than the clipboard.
• quattro has moved since this was opened: 129c67e switched the terminal branch to Ctrl+Shift+C/V and added Super+A select-all, so this branch now conflicts and would undo that change.

The second opinion, Codex at medium effort, was given both pull requests without my conclusion. It also recommended #13007, and it explained the group mismatch described above. Its independence is not guaranteed. It raised points for #13007's own review too: it runs xkbcli synchronously on first use, and it reads only the global keyboard config.

This is waiting on the maintainer to choose between the two approaches. Nothing more is needed from you now.

[omarchybot]

Thank you for this, @janhesters. #13007 fixes the same problem in a way the review judged better, so this is closed in favour of it. If it does not cover your case, please say so there.

Closed at the maintainer's request. The review comment above has the details; it was done by Claude Opus 5.5 with Codex Medium as a second opinion, whose agreement is not independent.