Superscript and Subscript (SGR 73, 74, 75)

[mnemnion]

These aren't ECMA standardized, and don't exist in XTerm. They're supported by minTTY and Wezterm, possibly more but at least those. Here's some background, there are more canonical / historical printer codes for these attributes, but XTerm recently introduced a query for XTMODKEYS which conflicts with those other versions, and even more recently, a second way to query using a DECQRSS sequence, which may deprecate the conflicting sequence over time.

VTE doesn't support either of them, but specifically won't support the ones listed in the title.

My take is basically: super and subscript are nice, I don't personally care about them being ahistorical and nonstandard, XTerm should have been using DECQRSS to begin with, and it's less conceptual burden on application code to use familiar SGR style for these sequences.

As a point of interest, the historical private-use codes were printer only, are called DECSGR in the literature, and CSI ?4 m activates subscript, with CSI ?24 m deactivating it, and superscript using ?5 and ?25. These can be considered more correct because the ? makes them a private sequence. But then again, ECMA 48 is, shall we say, no longer leading the way for terminal emulators, and standards should respond to facts on the ground.

The version I'm proposing here uses CSI 73 m for subscript, CSI 74 m for superscript, and CSI 75 m for neutral, resetting either of these sequences. The latest, 5th edition of ECMA 48 is silent on the subject of any SGR code larger than 65, but Xterm has used the 90 and 100 sequences for a long time, which Ghostty also supports, so the cat is out of the bag on that. I do remember 1991, but it was a long time ago.

I know that Ghostty has some basic support for modifyOtherKeys, I haven't tried querying it so I don't know if there's already a conflict with the DECSGR variants. Using the nonstandard SGR versions (as here suggested) would avoid such a conflict arising, however. If the DECSGR variants were to catch on in future, it would not be out of the question to support them both.