fix(input): type AltGr characters in the command, search and filter prompts - #694

Problem

On a German, Nordic, Polish or Portuguese keyboard, AltGr is the only way to type @, \, |, [, ], {, }, ~ and a pile of accented letters. On Windows none of those characters can be entered into tuicr's : command line, its / searches, or the i / e file-tree filters. The keypress is silently swallowed. The filters hurt most, because they take regexes and a regex without [, ], {, } or | is not much of a regex.

Repro (Windows, any layout with an AltGr level)

1. Press i in the file tree to open the include filter.
2. Press AltGr+8 (German) to type [.

Nothing appears. Same for : and /. The comment box, by contrast, takes the character fine, which is what made me look at the key map rather than at the terminal.

Cause

The Windows console reports AltGr as RIGHT_ALT_PRESSED set together with LEFT_CTRL_PRESSED. crossterm turns that into KeyModifiers::CONTROL | KeyModifiers::ALT and delivers the already-composed character, so AltGr+8 arrives as KeyCode::Char('[') with both modifier bits set. The mapping lives in crossterm-0.29.0/src/event/sys/windows/parse.rs, in impl From<&ControlKeyState> for KeyModifiers: LEFT_CTRL_PRESSED | RIGHT_CTRL_PRESSED sets CONTROL and LEFT_ALT_PRESSED | RIGHT_ALT_PRESSED sets ALT, with no AltGr special case in between.

All four text prompts in src/input/keybindings.rs ended their Char handling with the same arm:

(KeyCode::Char(c), KeyModifiers::NONE | KeyModifiers::SHIFT) => Action::InsertChar(c),
_ => Action::None,

map_command_mode, map_search_mode, map_file_tree_prompt_mode and map_target_filter_mode all had it, so a CONTROL | ALT character missed the arm and fell to Action::None.

map_comment_mode ends with (KeyCode::Char(c), _) => Action::InsertChar(c) instead, which is why the comment box was unaffected and the four prompts disagreed with it.

Fix

Add is_altgr_text() and one arm per prompt that accepts a Char carrying both CONTROL and ALT. It sits after the Ctrl-only chords, which match on KeyModifiers::CONTROL exactly, so Ctrl-w still deletes a word and Ctrl-u still clears the line. This is not a new behaviour for tuicr, it is the behaviour the comment box already had, applied to the other four prompts.

Tests

• should_type_altgr_composed_characters_in_every_text_prompt feeds @ \ [ ] { } | ~ ą with CONTROL | ALT to all four prompt maps and expects InsertChar. On b55e218 it fails on the first assertion: left: None, right: InsertChar('@').
• should_keep_ctrl_editing_chords_out_of_the_altgr_arm pins Ctrl-w and Ctrl-u in all four prompts so the new arm cannot swallow them.

Both are plain key-map unit tests, no VCS and no platform APIs, so they run the same everywhere.

Gates on this branch, all clean: cargo test 1582 passed / 0 failed / 4 ignored (1580 passed on b55e218, plus the two above), cargo fmt --all --check, cargo clippy -- -D warnings, and cargo clippy --all-targets -- -D warnings.

I do not have a Windows box, so the repro above is read off crossterm's Windows parser rather than observed. The fix and both tests are platform-independent.