Re: [RFC] Io\Terminal

Hi On 2026-10-02 22:38, Pratik Bhujel wrote:

I also checked Windows because I did not want to assume the POSIX PTY mechanism translated there. It does not directly, since proc_open() on Windows does not provide the same PTY descriptor. I built the current branch on Windows 11 ARM64 and exercised the native console path instead. The PHP side was just:

    $t = Io\Terminal\SystemTerminal::fromStdio();
    var_dump($t->readKey());

A small harness attached to a real Windows console injected KEY_EVENT records into CONIN$ with WriteConsoleInputW(). Injecting Up produced:

    enum(Io\Terminal\Key::Up)

[…] straightforward cross-platform testing seam is still relevant for Windows code that directly consumes readKey().

I know nothing about Windows, but am seeing that proc_open() offers a create_new_console option that is documented as:

create_new_console (windows only): the new process has a new console, instead of inheriting its parent's console

Is that perhaps already all that is required? Or would a (Windows-specific) helper Io\Terminal\inject_fake_keypress() outside of the main terminal API be helpful?

On the interface question, Tim's objections to the current Terminal/ModeToken shape still make sense to me, especially the ModeToken case where a userland token can satisfy the interface but cannot actually be restored by the native terminal. At the same time, after checking Windows I don't think I can honestly say that php://memory or stream injection alone makes the interface unnecessary everywhere. It clearly solves readLine(), and the PTY gives us a good POSIX integration seam, but Windows userland code directly consuming readKey() does not have the same pure-PHP PTY seam today.

It sounds to me that “PHP is unable to spawn terminals on Windows” is an orthogonal concern and a pre-existing limitation of e.g. the proc_open() API. The lack of Windows support must not influence the design of the Io\Terminal API to introduce a “short term” workaround that will become obsolete as soon as PHP will be able to spawn terminals on Windows, but that will affect the Io\Terminal API in a negative way for eternity. We should try very hard that every new API we add to the standard library is well-designed and convenient to use for 15+ years without introducing breaking changes. Perhaps Ilia’s suggestion of just allowing a php://memory stream is okay, keeps readKey() capabilities in sync with readLine() and fills gap until proc_open() is extended for proper end-to-end testing? Best regards Tim Düsterhus