zellij: tmux-faithful keybinds (clear-defaults; only Ctrl-\ global)

[bddap-bot]

Follow-up to #19 (merged). Goal: make Ctrl \ behave like tmux's prefix in zellij, and keep Ctrl \ usable at both layers when tmux is nested inside zellij (or vice-versa). Three commits.

1. zellij: tmux-faithful keybinds (config.kdl) — the actual fix

Fixes the owner complaint: "zellij hijacks my Ctrl-p/n, Ctrl-f and friends." Stock zellij binds ~a dozen Ctrl/Alt chords globally (Ctrl-p/t/n/h/s/o/g/q, plus Alt-f/n/…) as mode-switches, stealing them from the shell. (Ctrl-f isn't itself a stock bind — Alt-f is — but clear-defaults frees every Ctrl/Alt chord regardless, so Ctrl-f falls through too.) The previous config rebound the prefix to Ctrl \ but left clear-defaults=false, so all the stock global binds still stole keys.

• clear-defaults=true — nuke every stock bind.
• One global capture: Ctrl \ → tmux mode (shared_except "tmux" "scroll" "renametab", so the prefix can send-prefix inside tmux mode and doesn't yank you out of the text/scroll sub-modes). Every other Ctrl/Alt key now falls through to the running program.
• tmux-mode table modeled on tmux's prefix + ~/.tmux.conf: %/" splits, hjkl+arrows focus, o/z/x, Space=next-layout, c/n/p/&+1-9 tabs, d detach, , rename, [ scroll. scroll/renametab get explicit escape binds (clear-defaults wiped the stock ones).
• send-prefix passthrough (the nested-multiplexer pattern): in tmux mode, Ctrl \ Ctrl \ → Write 28 (literal Ctrl-) to the pane, matching .tmux.conf's bind "C-\\" send-prefix. So a tmux running inside a zellij pane still gets its own Ctrl \ prefix.

Why this gives you Ctrl \ in both: zellij defaults support_kitty_keyboard_protocol true, so in a kitty-capable terminal (Alacritty) it receives Ctrl \ as a kitty CSI-u sequence and the prefix fires. tmux doesn't request the kitty protocol, so it keeps receiving Ctrl \ as the legacy 0x1c byte and its prefix fires too. The two coexist.

2. zellij: Esc / Ctrl-c aborts the tmux-mode prefix (config.kdl)

Caught in the pre-merge review. With clear-defaults=true an unbound key in tmux mode is swallowed (you stay in-mode), so a stray prefix used to strand you in tmux mode with only the action keys as a way out. Now Esc/Ctrl c drop back to normal, like tmux after a stray prefix.

3. alacritty: drop an inert ReceiveChar binding on Ctrl-Backslash (alacritty.toml)

Cruft cleanup, not a functional fix — flagging the honest story because my first pass got it wrong. I initially thought this binding forced the legacy 0x1c byte and starved zellij of the CSI-u sequence. It doesn't: Alacritty's keyboard handler makes a ReceiveChar binding a no-op for byte output (*suppress_chars.get_or_insert(true) &= action != ReceiveChar leaves it unsuppressed = same as no binding), and the legacy-vs-CSI-u choice is taken purely from terminal keyboard mode, never from a binding (verified against Alacritty source v0.13–v0.15/master). So it neither blocked zellij nor was needed for tmux. Removed as dead config; no behavior change.

Testing — verified vs not

• Verified here: zellij setup --check passes on the rendered config.kdl (real zellij 0.43.1; confirmed it actually parses via a broken-KDL negative control that exits 1). alacritty.toml parses clean (python tomllib). Write 28 == 0x1c == Ctrl-. The Alacritty ReceiveChar no-op claim is read straight from Alacritty source; the zellij CSI-u requirement is zellij-org/zellij#4509. Reviewed by a fan-out reviewer loop (correctness/byte-protocol, KDL, taste) — that loop is what caught both the missing Esc escape and the Alacritty misdiagnosis.
• NOT verified live: no headless terminal here, so I could not confirm on your actual Alacritty that the zellij prefix fires (it should, given default kitty protocol) or press-test tmux nesting. The keybind change is the substance; commit 3 is inert by source analysis.
• Caveat for the owner: the zellij prefix works only while support_kitty_keyboard_protocol stays at its default true. If it's ever set false, zellij would get the 0x1c byte, which its input parser doesn't decode as Ctrl \ (the #4509 failure) — and no Alacritty setting fixes that.