Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

self reporting sequence #4982

Open
jerch opened this issue Mar 5, 2024 · 0 comments
Open

self reporting sequence #4982

jerch opened this issue Mar 5, 2024 · 0 comments
Labels
area/api type/enhancement Features or improvements to existing features

Comments

@jerch
Copy link
Member

jerch commented Mar 5, 2024

Currently it is almost impossible for app side to reliably figure out xterm.js as TE or its version. Linked to that are supported/unsupported features, or additions from addons.

Suggestion
Establish a self reporting sequence, which gives enough insights about TE version and switched on features. I have no yet thought about the proper sequence format, but I think something along this would do:

SelfReport
query:    CSI  <free finalizer>
response: OSC  <some_free_id>  ; xterm.js ; x.y.z ; featureA ; ... ST
with these fields:
  [0] - name of the TE (mandatory)
  [1] - TE version (mandatory)
  followed by list of enabled features (all optional)

TE name and version are self explaining, additionally these fields should be customizable by integrators, eg. vscode might want to place there "vscode-terminal" and its vscode release version.

The list of enabled features is more tricky to set up. Basically we'd have to go through all customizable aspects of xterm.js and come up with an identifier, quick examples coming to my mind:

  • "unicodeX" to announce unicode version X
  • "domrenderer" (in case we want to announce the renderer type)
  • "hyperlinks" to indicate OSC8 support

Finally, addons might want to add features, if they are loaded (needs API option to extend feature list):

  • "weblinks" to indicate auto hyperlinking of URLs (weblinks addon)
  • "unicode15" and "grapheme" from grapheme addon
  • "sixel" and "IIP" from image addon
  • "webglrenderer" from webgl renderer
  • "clipboard" to indicate OSC52 clipboard support

I am not sure yet, whether a simple feature listing will do, or if we need a key-value structure instead.
Up for discussion.

@jerch jerch added type/enhancement Features or improvements to existing features area/api labels Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api type/enhancement Features or improvements to existing features
Projects
None yet
Development

No branches or pull requests

1 participant