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.
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:
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:
Finally, addons might want to add features, if they are loaded (needs API option to extend feature list):
I am not sure yet, whether a simple feature listing will do, or if we need a key-value structure instead. Up for discussion.