Terminal I/O. #62
Terminal I/O. #62
Conversation
Add an API for portable terminal I/O support, including escape sequences and control codes. This aims to cover features used by most applications while remaining portable across popular terminals.
Co-authored-by: Jacob Lifshay <[email protected]>
There's more room for improvement here, but this should hopefully provide a reasonable path that can be evaluated.
| record rows-and-columns { | ||
| rows: u16, | ||
| columns: u16, | ||
| } | ||
| } | ||
|
|
||
| /// An interface providing an optional `terminal-input` for stdin as a |
There was a problem hiding this comment.
should there also be an interface that's equivalent to opening CON or /dev/tty? this is used by things like sudo tee where the inputs/outputs may be redirected but sudo still accesses the controlling terminal to write out the password prompt and read in the password.
There was a problem hiding this comment.
I think it would be straightforward to have an API that returns a terminal-input. terminal-output, and streams for the controlling terminal (alongside the stdio functions). That's independent of what the terminal-input and terminal-output interfaces look like though, so that could be proposed separately.
A potential consideration is that we may not always want sandboxed programs to be able to do that, because that would mean they could bypass stdio redirects and potentially grab input from the terminal meant for another application. So we'd want to think through the use cases.
…odes. Support Bold, Faint, and attribute resets. And move bracketed paste and invisible cursor out of full-screen so that they can be used in all modes.
Co-authored-by: Jacob Lifshay <[email protected]>
Escape sequences are now "recognized" rather than being "defined for the appropriate mode", output terminals are now more completely described, and various sentences are tidied up.
Also, switch to the Unicode "maximal subparts" reference, which is the same algorithm, but a simpler reference here.
It's ok if terminal apply additional transformations, but we don't want implementations passing through additional control codes.
Add an API for portable terminal I/O support, including escape sequences and control codes. This aims to cover features used by most applications while remaining portable across popular terminals.
I've marked this a draft PR, as it's very much a rough draft right now. I don't expect to have a lot of time for this, so any help in identifying missing features, errors, or overreaches, or prototyping, is appreciated! Alternative proposals that take a completely different approach would be valuable as well!