On Tue, Sep 29, 2026, Larry Garfield wrote: > Thanks, that does make it clearer! So the reason to use raw mode yourself > would be, for instance, for a game where you're capturing the arrow keys and > WASD, or something like that? (Concrete examples would help.)
Yep, exactly. Games are one example, but interactive TUIs are probably the more common case here: menus, search/select UIs, editors, anything that needs to react to individual key presses and redraw without waiting for Enter. > This also makes me think that a readLine() method makes sense in this base > tool, not at a higher level. I did think about that. My hesitation is that normal PHP streams already handle line-oriented reads pretty well, while this proposal is mainly trying to cover the terminal-specific bits that aren't exposed portably today. So for the first core version I'd rather keep readLine() out instead of duplicating fgets()-style behavior. The extension can still be useful as a backport/reference implementation and carry convenience APIs that don't necessarily need to be in core. > Conventions for Internals say to not use a *Interface suffix. It's > unnecessary. Thanks, I hadn't considered that core naming convention when I added the interfaces. I used the *Interface names mainly so I could add the mockable contract without renaming the existing Terminal and ModeToken classes. I see the naming issue though. I want to check whether changing the class/interface split is worth the additional public API churn before changing it again. > For ModeToken, I'm not sure if it makes sense to have separate classes for > each core terminal. It's just an opaque value object, really, so I don't know > what pattern we'd want here. Yeah, I agree. I don't see much value in separate token classes either. The main thing I need to preserve is validating native tokens against the logical terminal they belong to, while still keeping userland implementations mockable. Best regards, Pratik
