Improvements to TTY

[hoodmane]

Currently TTY has a lot of flaws:

1. The TTY operations are character-based. This tends is hard to work with and requires extra buffers and code complexity and is slow. For instance, the default Node getChar implementation creates a temporary buffer, uses readSync() which writes into a buffer, and then has to return one character at a time from that buffer. But the stream API calls read() with a buffer, it's only TTY's read implementation that calls getChar() repeatedly and it is more complicated because of it.
2. In Node, stdin/stdout/stderr should default to having isatty reflect the value on process.stdin/ stdout/stderr.
3. TTY.register() always creates a TTY with isatty() returning true and requires getChar() / putChar(). If I want TTY to be false, I have to make read and write handlers instead. This makes (2) unnecessarily difficult.
4. If reading from stdin is implemented with prompt(), isatty(stdin) should be false, since prompt does not behave like a tty. If writing to stdout/stderr is implemented with console.log() or console.warn() isatty should be false since partial lines are not handled well.

I work around this in Pyodide by avoiding use of TTY, and instead using my own implementation: https://github.com/pyodide/pyodide/blob/main/src/js/streams.ts
But I keep having to copy parts of this into other projects, for instance CPython has its own copy here:
https://github.com/python/cpython/blob/main/Platforms/emscripten/streams.mjs
It would be helpful to solve this in Emscripten.

For the performance part of this, see #16755.

[sbc100]

I completely agree. I'd love to see our TTY handling improved.

Regarding (2) specifically I believe that was actually fixed last week in #26530, at least for NODERAWFS.

If you have ideas for how to upstream you changes and/or simplify/improve the way emscripten handles things upstream please fire away!

[hoodmane]

I am working on a branch. I expect it'll take some further discussion before we can agree on what to do and it might take a few tries but it should be easier to have the discussion as PR review than in this issue.

[sbc100]

One or my ideas is to try to add xterm.js integration into the test suite so we can verify that the TTY behaivour is working as expected. I'd also like to combine this with JSPI/ASYNCIFY for __syscall_read on the TTY so that we can get a bunch of terminal apps working in single threaded more. (Also in PROXY_TO_PTHREAD too)

[hoodmane]

Currently libtty has no test coverage so I guess I should start by adding tests for libtty.

[sbc100]

I'm also not sure about the design of libtty or the whole getChar thing.. I don't know it makes sense to expose anyother than normal posix stuff here.

[hoodmane]

How do you feel about backwards compatibility? Can we just delete libtty entirely?

[hoodmane]

I was assuming we do care, in which case #26613 should help. But if not I could just close that.

[sbc100]

I think we if we have a idea for a better libtty design we can make a case for breaking back compat. I don't think emscripten users are normally extending to modifying this low level interface.