Xterm.js: Consider supporting adding custom APC handlers, similar to CSI/OSC handlers.

[oising]

It's not clear to me if an APC (application program command -- ESC_<string>ST) could be handled by an application hosting xtermjs by using the EscHandler plumbing, but it would useful to allow it for commands run in the terminal to pass commands to the terminal hosting application. An example might be for an open <file> command in the VS code terminal that emits a sequence to instruct VS Code to load <file> into the editor, etc. Such a command could be written in batch, bash, powershell or anything that can write VT. This would allow very easy dispatch of editor commands from the terminal, should VS code opt to wire up an APC handler.

[Tyriar]

We wanted to add an addEscHandler API anyway 👍

[jerch]

@oising Is there a specific reason why you would like to see this under APC? Currently APC and PM realms are not specified by any official document, there is no prior art to learn from beside the global ignore rule (which almost every VT parser applies) and some private usage in one or two emulators. Thus we'd have to spec this carefully first, not sure if the spec hassles are worth it since DCS and OSC commands can carry almost the same payload (and binary data would have to be escaped/transport encoded anyway to avoid escape sequence clashes).

In this regard I really like the way iTerm2 handles this - it has its own private OSC command (OSC 1337 ... ST), which supports tons of private submodes. I'd favor this or a DCS equivalent more than getting into APC business.

[Tyriar]

We can leave the APC discussion to https://github.com/microsoft/vscode/issues/77145, I'm not sure that's the direction we want to go. But I think we should expose the handler API as suggested regardless.

[oising]

@jerch I guess I'd prefer APC because well, OSC is for operating system commands, and APC is for applications. It seems that in this case anyway, the distinction is clear. In the case for both methods, namespacing is equally out in the open (e.g. iTerm2 chose 1337 for OSC - leet reference aside - fairly arbitrarily) -- but I will submit that an unrecognized OSC sequence is less likely to interfere with rendering than an APC sequence. The latter's payload _should_ be ignored and not rendered but frequently is rendered in common terminals as far as I can tell (because they intrinsically don't understand/support APC). So perhaps you're right.

[jerch]

I think we can close this issue? @oising Feel free to open a new issue if you have unanswered questions or ideas regarding the issue. Imho the big "picture discussion" is better done at the vscode thread.

Regarding extending the parser with more add... methods - I already have this on the schedule.