[idea] Extend prefix-mode ASCII input source switching to Linux (fcitx5)

[maedana]

idea / problem

Related: #380 (macOS), #1786 (Windows). Previously reported as #2845, which was closed as a feature request with a pointer to Ideas.

On Linux with a CJK IME active, the same problem #380 describes for macOS and #1786 describes for Windows happens: after pressing the prefix key, the next key (c, v, h/j/k/l, ...) gets composed by the IME instead of being read as a prefix command. switch_ascii_input_source_in_prefix currently works on macOS and Windows; on Linux it is a no-op.

Modifier-based bindings like prefix+ctrl+1..9 still work in the same state, because modified keys pass through the IME untouched. It is only the plain-letter follow-ups that disappear.

requested change

Support switch_ascii_input_source_in_prefix on Linux too: while prefix mode (and prefix-launched modes) is active, temporarily put the input method into direct ASCII input, and restore it when returning to terminal input. At least for fcitx5 to start with — it exposes a direct-input state of its own, so this needs no hardcoded input method names.

Same contract as the existing platforms: opt-in under [experimental], best-effort, no-op when there is nothing to switch or the switch fails, restore on exit or cancel.

why you want this

Same UX gap as #380 and #1786, just on Linux. Linux is the last platform where prefix commands are unreliable under a non-Latin IME, so the feature is incomplete without it.

[maedana]

I have this working locally for fcitx5 with tests and manual verification, so I'm ready to open a PR. Could I get an issue for it? @ogulcancelik

[maedana]

I ended up solving this outside of herdr, so I'd like to withdraw this idea rather than send the PR I mentioned above.

For anyone landing here with the same problem on Linux/X11: herdr doesn't actually need to know about the IME. XInput2 lets you observe key input without grabbing it, so a small daemon can watch for the prefix key and switch the IME off while the key itself still reaches herdr untouched.

ime_off='[ "$(xdotool getactivewindow getwindowclassname)" = Xfce4-terminal ] && fcitx5-remote -c'

stdbuf -oL xinput test-xi2 --root | awk -v cmd="$ime_off" '
	function ctrl_held(   k) { for (k in ctrl) if (ctrl[k]) return 1 }
	/RawKeyPress/   { press = 1; key_event = 1; next }
	/RawKeyRelease/ { press = 0; key_event = 1; next }
	/detail:/ && key_event {
		key_event = 0
		if ($2 == 37 || $2 == 66 || $2 == 105) { ctrl[$2] = press; next }  # Ctrl
		if (press && $2 == 28 && ctrl_held()) system(cmd)                 # t
	}
'

Two things that cost me time, in case they save someone else's:

• xinput block-buffers when its stdout is a pipe, so stdbuf -oL is required — without it the detection lags badly.
• One key press emits both a RawKeyPress and a regular KeyPress, and both carry a detail: line. Hence the key_event flag; without it every press fires twice.

To be clear, this is strictly less than what switch_ascii_input_source_in_prefix does on macOS: it turns the IME off and never restores the previous state when prefix mode exits. That trade-off is fine for my usage, and it's why this belongs in my dotfiles rather than in herdr.

X11 only, too — on Wayland you'd probably need something like keyd to rewrite the key at the uinput level.