This was something suggested on IRC Discord, and while I'm not entirely sure about the practicality of it, it's definitely worth discussing:

When typing at a computer, we send all key presses to the server, resume the appropriate computer, print to the screen, and send the update to the client. As all of this is done on the server tick, this means there's at best a 50ms latency between typing and the character appearing. When compounded with a high ping, low TPS, or a saturated computer thread, this round trip delay gets even higher.

One possible solution would be to introduce something similar to "local echo/edit mode", as provided by VT1xx (see the SRM and DECEDM modes). Effectively, when typing we could display the character on the client immediately, and then proceed with our original update.

This has the advantage that the user receives visual feedback on what they've typed already, even if they're not going to receive all the other fancy things like auto-completion.

That said, I can see several potential issues and complications, which make me a little nervous about this:

• Obviously this isn't something which should always be on - you don't want the wasd keys in a game to display on the screen. The obvious heuristic here is "is the cursor blinking" - this probably means we're prompting for user input.

  This also raises some issues when the prompt doesn't take up the whole line. I assume we'd then need to expose some functionality for what the bounds of the prompt are, which is ... a pain.

• There seems to be a lot of complexity in keeping the terminal consistent between the client and server. Our current model is very simple - just send the entire buffer any time it changes (though I'm hoping to fix this as part of #112). However, with this, we need to bear in mind what happens when the user types something and then receives a terminal update which doesn't include those characters yet - ideally we wouldn't remove them, as this makes things even more confusing, but we obviously don't want to end up desynchronised either.

I think if we could get this working in a reasonable manner, it would be a massive QoL improvement. However I think there's a lot of potential for gnarly things within the implementation, as CC really does not follow the model of a classical terminal.

Having had a think about this, I'm not convinced the implementation complexity is worth it. If someone can find a way to make this work in a pretty simple and intuitive way, I'm more than happy to discuss it, but for now I think it's fine to leave it by the wayside.