supporting shell integration

[PerBothner]

"Shell integration" is a fairly high-usability feature. I know that some xterm.js-based applications support shell integration, most obviously vscode. However, the vscode logic is rather difficult to understand - there is a mess of handlers and events - I haven't been able to figure out how it all hangs together, and I'm not sure it's the right approach for other applications.

It is important that shell integration properties (prompt, input, output) be preserved by serialization. This suggests to me using Markers or Decorations isn't the right approach. (Decorations look like they're very inefficient if there are many of them.) Better would be to attach shell integration properties to the BufferLine (or the LogicalLine if PR #5797 is adopted).

On a character basis, we need at least 2 bits to mark if a cell is in a prompt or in user input. But there way be other information we want to store, such as the exit code, so it makes to define a CommandInfo class. The CommandInfo object could be attached to the ExtendedAttrs - ot it could be attached to the BufferLine (or LogicalLine) object.

It would be nice to deal with the shell integration logic purely in an addon, but just as with URL links, it seems best to have the basic logic be supported by the core.

Comments/suggestions? Apologies if I have overlooked a previous discussion.

[Tyriar]

Shell integration is out of scope of the lib imo, xterm.js is a library that lets you implement a terminal on the web, shell integration inherently needs to execute code inside the shell and synchronize things between them, have a persistence layer if reconnecting, etc. It makes sense to have this live outside as it should live above whatever marries xterm.js and the pty/shell launching.

It's difficult to understand because it's very complicated to do correctly, especially with Windows as a target. There's also not one single way of implementing it, VS Code uses vscode-specific sequences not the typically OSC 133 ones.

It is important that shell integration properties (prompt, input, output) be preserved by serialization. This suggests to me using Markers or Decorations isn't the right approach. (Decorations look like they're very inefficient if there are many of them.) Better would be to attach shell integration properties to the BufferLine (or the LogicalLine if PR #5797 is adopted).

Markers only have performance concerns if you're creating and disposing of a lot of them in quick succession, like with the search addon. For shell integration you only need markers around the command line and the end of the output.

Comments/suggestions? Apologies if I have overlooked a previous discussion.

For basic non-Windows shell integration I'd recommend handling OSC 133 A, B, C and D. Add markers for those and you've basically got your shell integration. Then for cwd detection OSC 1337 ; CurrentDir=<Cwd> ST and maybe OSC 7 ; scheme://cwd ST and OSC 9 ; 9 ; <cwd> ST (yes it's a bit of a mess).