Typed characters never reach elements: SpectreConsoleProvider drops ConsoleKeyInfo.KeyChar, so text input and shifted symbols are impossible

[matt-edmondson]

What's wrong

TUI/Services/SpectreConsoleProvider.cs (around lines 84-96) reads a key with Console.ReadKey(true) and returns InputResult.FromKey(keyInfo.Key, keyInfo.Modifiers). It discards keyInfo.KeyChar.

The model supports characters: InputResult.Character, InputResult.FromCharacter and InputType.Character all exist (TUI/Models/InputResult.cs:54). But nothing in the repository creates a character result. SpectreConsoleProvider is the only real provider, so no element can ever receive one.

Failure scenario

• Typing ! reaches the element as ConsoleKey.D1 + Shift, so it cannot tell ! from 1.
• /, ?, @, " arrive as Oem* keys, which differ from one keyboard layout to another.
• Caps Lock state is lost, so upper and lower case can't be recovered reliably.
• Non-US layouts and dead-key or IME composition produce the wrong characters.

As a result, a text box, search field, or any other text-entry element can't be built on this library.

Suggested fix / acceptance criteria

• When keyInfo.KeyChar is printable (not '\0' and not a control character), fill in InputResult.Character as well as the key and modifiers.
• Filling in both fields keeps existing key-based handlers working.
• Add a provider-level or InputResult test showing that a Shift+D1 key info carries Character == '!'.

[matt-edmondson]

Triage

• Category: Bug
• Priority: High. No element can receive typed characters, so text entry (text boxes, search fields) can't be built on the library, and shifted symbols and non-US layouts come through wrong. The fix is small and additive.
• Area / suggested assignee: input pipeline (SpectreConsoleProvider.ReadKey → InputResult). Owner: @matt-edmondson
• Duplicates / in progress: no duplicate or open PR. SpectreConsoleProvider.SetCursorVisibility moves the cursor and toggles visibility on System.Console instead of the injected IAnsiConsole #153 is in the same provider file and could share a PR. The earlier input-loop issues (UIApplication.RunAsync busy-loops at 100% CPU forever when stdin is redirected (≈200k failed ReadKey calls/sec) #143 busy loop on redirected stdin, RunAsync leaves a Console.ReadKey pending after shutdown, so the next keypress (in the host or in a second RunAsync) is swallowed #149 pending ReadKey after shutdown) touch the same read path, so check them for conflicts.
• Next step: fill in InputResult.Character from a printable KeyChar alongside the key and modifiers, and add the Shift+D1 → '!' test.

---

Generated by Claude Code