IIP support detection

[AnonymouX47]

Hello!

Currently, I'm unable to figure out any means to detect support for IIP (in xterm.js, with this addon enabled).

The methods I'm currently aware of are:

1. Detecting the name [and version] of the TE using either:

   • Environment variables: Unfortunately, I'm not sure these can be set by xterm.js since it doesn't directly execute the program running in the terminal.
   • XTVERSION (CSI > q): This is currently not implemented by xterm.js, it seems.

   All in all, this method would be flawed if implemented by xterm.js since this addon may or may not be enabled; plus it's less preferred since it requires an application to keep a database of TE names [and versions] that support the protocol.

2. iTerm2's OSC 1337 ; ReportCellSize ST query (see this page).

   A number of TEs I've tested that implement the IIP also implement this query including iTerm2, Wezterm, Konsole, Termux Monet (Android).

I'd like to suggest the implementation of the later, as it is within the scope of this addon and is the preferred method.

Thank you. 🙏

[jerch]

@AnonymouX47 Yeah feature detection is currently an issue on a very fundamental scale in TEs, esp. for features outside of the terminfo database. And as you already wrote, the problem is even more nuanced with xterm.js, as it more a terminal lib than a ready to ship TE, so it depends highly on what integrators enable in their final TE.

I agree, implementing ReportCellSize seems like a nice way to indicate IIP support indirectly, so I'd prolly go with that one. Thx for the headsup.

[AnonymouX47]

Thanks for the quick response.

I see you opened a corresponding issue on the xterm.js repo. I assumed it was somehow possible to implement it within the addon since I noticed the response to DA (Send Device Attributes, CSI c) is different depending on whether this addon is enabled or not.

Anyways, if this behaviour is achievable for ReportCellSize (i.e no/empty reponse when this addon is not enabled), it'd be really good as we don't want the TE "reporting support" for IIP when this addon not enabled.

Thank you.

[jerch]

Yeah I opened the issue over there, since the addon source is hosted there since ~6 months. This repo here is the legacy version, but I dont mind to keep graphics discussions here (in an incubator sense).

[AnonymouX47]

Oh, I see. Should probably close #49 then.

[jerch]

Oha good find - closed 😅

[AnonymouX47]

@gnachman, sorry to bother you. Since I noticed you on #57, I thought I might as well call your attention to this.

There is currently no specified means to detect support for this protocol.

What're your thoughts about specifying (or at least, suggesting in the spec) that the ReportCellSize sequence be implemented alongside the protocol?

Personally, I feel this is much easier than inventing a new method (supposedly a query) since almost all (if not all; the only others I'm aware of and yet to test are mintty and hterm) TEs implementing the protocol already implement this sequence. Also, implementing this sequence does no harm to any TEs that may implement the protocol in the future.

Yes, it'd be good to have a more specific and extensive sequence (possibly reporting supported inline formats) but I'm concerned about how long and how much it'll take to make such go round TEs that have already implemented the protocol.

Thank you.

[gnachman]

ReportCellSize as an indicator of support makes sense. I can add that.

Version 3.5 (currently in beta), which I am planning to ship as soon as I possibly can (probably in a month or so), implements a new control sequence for capability discovery. The capability protocol is documented here:

https://iterm2.com/feature-reporting/index.html

It's long and detailed but the short version is this: send \e]1337;Capabilities\a and you'll get back something like \e]1337;Capabilities=T3LrMSc7UUw9Ts3BFGsSyHNoSxF\e.

The letter soup defines a collection of capabilities, each beginning with a capital letter. The F capability indicates the IIP is supported.

[AnonymouX47]

ReportCellSize as an indicator of support makes sense. I can add that.

Thank you 👍

Version 3.5 (currently in beta), which I am planning to ship as soon as I possibly can (probably in a month or so), implements a new control sequence for capability discovery. The capability protocol is documented here:

https://iterm2.com/feature-reporting/index.html

It's long and detailed but the short version is this: send \e]1337;Capabilities\a and you'll get back something like \e]1337;Capabilities=T3LrMSc7UUw9Ts3BFGsSyHNoSxF\e.

The letter soup defines a collection of capabilities, each beginning with a capital letter. The F capability indicates the IIP is supported.

Hmm... Interesting, that was quite a read.

Is the TERM_FEATURES protocol by any means open to discussion? And if so, is there any ongoing?

[gnachman]

ReportCellSize as an indicator of support makes sense. I can add that.

Thank you 👍

Version 3.5 (currently in beta), which I am planning to ship as soon as I possibly can (probably in a month or so), implements a new control sequence for capability discovery. The capability protocol is documented here:
https://iterm2.com/feature-reporting/index.html
It's long and detailed but the short version is this: send \e]1337;Capabilities\a and you'll get back something like \e]1337;Capabilities=T3LrMSc7UUw9Ts3BFGsSyHNoSxF\e.
The letter soup defines a collection of capabilities, each beginning with a capital letter. The F capability indicates the IIP is supported.

Hmm... Interesting, that was quite a read.

Is the TERM_FEATURES protocol by any means open to discussion? And if so, is there any ongoing?

It’s been through a ton of review some years ago when it was first written but I’m open to comments. It hasn’t been published yet.