Summary
Replace the polling-based input system with a proper platform abstraction layer that provides event-driven console I/O. This addresses Windows compatibility issues and eliminates the 10ms input latency caused by the current polling architecture.
Problem
The current ConsoleInputSource uses a 10ms polling loop with Console.KeyAvailable + Console.ReadKey. This is an architectural flaw that causes:
- Input latency - Minimum 10ms delay before input is processed
- CPU usage - Constant polling even when idle
- Windows issues - No explicit VT100 enablement, causing rendering problems in some terminals (Cmder/ConEmu)
- No resize signals - Terminal resize is also polled instead of signal-based (Unix)
Solution
Create an IPlatformConsole interface with platform-specific implementations:
- WindowsConsole - P/Invoke for
SetConsoleMode (VT100), ReadConsoleInputW (event-driven)
- UnixConsole - termios raw mode,
select()/poll() on stdin, SIGWINCH signal handler
- FallbackConsole - Current polling logic for unsupported platforms
Child Issues
Acceptance Criteria
Summary
Replace the polling-based input system with a proper platform abstraction layer that provides event-driven console I/O. This addresses Windows compatibility issues and eliminates the 10ms input latency caused by the current polling architecture.
Problem
The current
ConsoleInputSourceuses a 10ms polling loop withConsole.KeyAvailable+Console.ReadKey. This is an architectural flaw that causes:Solution
Create an
IPlatformConsoleinterface with platform-specific implementations:SetConsoleMode(VT100),ReadConsoleInputW(event-driven)select()/poll()on stdin, SIGWINCH signal handlerChild Issues
IPlatformConsoleinterface and console event typesTerminaApplicationConsoleInputSourceAcceptance Criteria