Ghost text for high-latency terminal sessions

[ricklamers]

ghost-text.mov

Something similar to this xterm.js behavior would be nice. Any plans to support this? I searched for this feature in docs/issues/discussions but couldn't find it. Apologies if this is already supported/being discussed somewhere.

[00-kat]

Possibly relevant: #1934 (comment).

[rhodes-b]

xtermjs/xterm.js#887 (it seems it has multiple forks to continue the work I saw at least 2 not sure if any are still active) this seems very similar if not the thing you are asking for. Id say this is probably very out of scope for ghostty at least for along time as it basically means ghostty now has to run a mini shell to understand what specific shell sequences mean etc.

TL;DR if its not a ghostty keybind nor a escape seqence a terminal doesn't really know about the data it just passes it to the shell and the shell tells the terminal what to do like move cursor left or print the letter a here etc

it also means ghostty has to have 2 internal buffers, text in the scrollback and now text its waiting for a response from the shell from which if it was somehow wrong it needs to fix. I would think this would be pretty expensive speed wise to manage properly

This is not a "easy" feature to add due to both things I mentioned

Maybe like xterm.js this would be better suited as a plugin to libghostty

[00-kat]

Hold on. If I understood the scope of this properly, Ghostty would need to either:

1. Become the thing handling the network connection.
2. Monkey-patch SSH or something.

In xterm.js' case, I think it's the thing that deals with the network connection itself (or can directly communicate with the thing such as VSCode which deals with the network connection), so it's more feasible there, since you can show the text before you're told that it has reached the other side, but in Ghostty with something like SSH Ghostty cannot tell any distinction between a network connection and a local shell, right?

So I don't see how this is achievable without hacking around SSH.
Either that or I completely misinterpreted everything.

[ricklamers]

I think you guys might be overthinking this, it's just a minor UX feature of optimistic previewing input characters that are entered. Fine to roll them back if the actual session rejects them, maybe you can heuristically determine when this feature activates.

[rhodes-b]

I think you guys might be overthinking this, it's just a minor UX feature of optimistic previewing input characters that are entered. Fine to roll them back if the actual session rejects them, maybe you can heuristically determine when this feature activates.

I dont believe we are overthinking it. Like I stated ghostty has no idea what random keys mean (given its not a internal keybind). When you press a g for example ghostty sends that to the shell and the shell says terminal render this character and move the cursor over one. It would require a mini shell parser to achieve this behavior.

Yes I understand ghostty has some concept of input since it sends the keypresses but alot more of the work is done in the shell than you think it is

You cannot compare to a gui client like vscode since it controls alot more of the input handling

Like i also stated there is now state management of what ghostty thinks the shell is going to print vs what it actually prints. Those are now separate cursor states etc. There is alot more that needs to happen behind the scenes than one would imagine

Ghostty with something like SSH Ghostty cannot tell any distinction between a network connection and a local shell, right?

I agree ghostty wouldn't know a ssh client is running because the shell controlls all of that not the terminal. So it would take some "monkey patch" like you said to achieve this

[00-kat]

I think you guys might be overthinking this, it's just a minor UX feature of optimistic previewing input characters that are entered.

If I understand correctly, when you go to something like https://vscode.dev, the terminal isn't on your system while the UI is. VSCode can hence optimistically preview input characters before they get sent to the terminal itself, as the latency is from you to the terminal, and not you to the UI.
In Ghostty's case, Ghostty is on your system and it gets the input characters and sends it to the shell immediately. You won't have latency here. SSH then has to get it and send it over to the other side to the shell waiting over there. At this point, Ghostty no longer has control of those input characters, those have long since been sent to SSH. That is, Ghostty does not care what the running application does with the keypresses, whether that be position it on the prompt, send it to Antarctica or train an LLM on; all this is the running application's responsibility.

TL;DR: easier with something like VSCode, but all that overthinking is necessary because of how remote connections through Ghostty work.

Fine to roll them back if the actual session rejects them

Yeah, no. SSH never tells you about it, they just get swallowed by SSH.

maybe you can heuristically determine when this feature activates.

That would be all the text Bruce originally sent.

[00-kat]

I agree ghostty wouldn't know a ssh client is running because the shell controlls all of that not the terminal. So it would take some "monkey patch" like you said to achieve this

And that's not the issue, Ghostty can always parse its process tree (there have been other discussions where this solution was mentioned too). The issue is Ghostty knowing what SSH is doing, not whether SSH is running.

[ricklamers]

I will just add this is default behavior in VS Code/Cursor terminal so a lot of users will expect it.

[pluiedev]

You're the first to ever bring it up - and believe me, I've read thousands of discussions. I don't think it's nearly as common as you think.

[pluiedev]

I'm going to reject this for now for multiple reasons:

• Firstly, we don't have a builtin way of measuring what latency is, and figuring that out is completely out of the scope of a terminal emulator: it should be either the task of SSH or another tool that works closely with it.

• Secondly, even if we were to implement this, we would need to support animations that don't compromise performance. That's not currently possible as the graphics pipeline is synced to terminal cell rebuilding, and that is very slow and resource-intensive. (There's a reason why custom-shader-animation is off by default.)

I'm not saying this is a bad idea per se, but it's something that needs a complete overhaul of our rendering system and tighter integration with every part of the chain, and while we can achieve the former (indeed, it's on the roadmap) the latter is much harder to ask for outside of a tightly integrated environment like VS Code. It's just not feasible for SSH to concern itself with what specific terminal emulators do.

[ricklamers]

Totally accept those reasons. Thanks for considering!

[ricklamers]

Would be nice though :)

[mitchellh]

I approve of this rejection. I'll add that this is a better feature for a shell to implement (or SSH itself) than a terminal emulator in general. The running program on the host (i.e. ssh) has much better access to this information to do this.