Dead-key compose (^/¨/dead ~) silently fails inside terminal panes on Plasma 6 Wayland

[manuacl]

Bug

On KDE Plasma 6 Wayland without ibus / fcitx5 running, dead-key composition does not produce composed glyphs inside Limux terminal panes:

• ^ + e → expected ê, actual: the ^ glyph flashes on screen, then disappears when e is pressed; nothing composed lands in the terminal buffer
• Shift+^ (dead diaeresis) + e → expected ë, actual: same flash-and-drop, no ë
• AltGr+ñ / dead ~ + n → expected ñ, actual: nothing composed (on AZERTY variants that have a real dead_tilde)

The same dead keys compose normally in every other GTK app on the same system (gnome-text-editor, Firefox, Konsole), so it is isolated to Limux.

Environment

• KDE Plasma 6 Wayland (Bazzite Fedora 44)
• French AZERTY layout (variant unset)
• GTK_IM_MODULE unset → GTK4 picks the wayland slave inside IMMulticontext
• No ibus / fcitx5 daemon running
• Limux built from main (post-b3637e2)

Reproduction

1. KDE Plasma 6 Wayland session, French AZERTY (or any layout with dead_* keys), no IME daemon running.
2. Launch limux (or ./target/debug/limux with LD_LIBRARY_PATH=ghostty/zig-out/lib).
3. Open a workspace, focus a terminal pane.
4. Type ^ then e.

Expected: shell receives ê.
Actual: shell receives nothing; ^ appears as a preedit-style glyph then vanishes.

Root cause

GTK4's IMMulticontext defaults to the wayland slave on Wayland sessions without an IME daemon. That slave forwards key events to the compositor over text-input-v3:

• For a dead-key press, filter_keypress returns true (the slave claims the event) and a preedit_changed signal fires with the bare dead-key glyph as preedit text. KWin/Plasma 6 never delivers the follow-up commit.
• For the next key, the slave claims the event again and emits preedit_end without committing anything.

Limux's terminal IME state machine consumes both keystrokes (correctly, given the signals it received) but the compose result never materializes because the compositor never sent it.

GtkIMContextSimple does the compose in-process via libxkbcommon's tables and is not affected — confirmed by running GTK_IM_MODULE=simple limux, which fixes the bug.

Prior art

PR #20 (commit 536e6e9, "Fix search activation for IME and dead keys") added the original IMMulticontext plumbing and fixed the case where dead keys also accidentally triggered the search bar. That fix works when GTK picks a slave that drives compose itself (X11, or Wayland with ibus/fcitx5 active), so it covered the original reporter's environment. The Wayland-default case was not exercised — the PR's test plan checklist still has the ibus / fcitx rows unticked.

Proposed fix

Pair the existing IMMulticontext with a parallel GtkIMContextSimple. When the incoming keysym is a compose initiator (XK_dead_*, Multi_key) or the simple context is already mid-compose, bypass the multicontext entirely so the Wayland slave can never claim the event; otherwise keep the multicontext as primary so ibus / fcitx5 / CJK IMEs continue to work.

Branch: feat/dead-key-compose-fallback (commit 6795e42). Verified locally on the reporting machine.