contour
contour copied to clipboard
contour-terminal
Subscript and Superscript SGRs
Abstract
According to Wikipedia's article these SGRs implemented only in mintty. It would be nice to support these features in Contour.
Specification
From https://github.com/mintty/mintty/wiki/Tips#text-attributes-and-rendering
| enable | disable | attribute |
|---|---|---|
| 73 or ?4 | 75 or ?24 | superscript (*) |
| 74 or ?5 | 75 or ?24 | subscript (*) |
(*) Combined SGR 73;74 results in small characters at normal position. This does not apply to the alternative DEC private SGRs ?4 and ?5.
Tiny research: :) (mintty/src/wintext.c)
...
if (attr.attr & (ATTR_SUBSCR | ATTR_SUPERSCR))
{
y = y * 12 / 20;
x = x * 12 / 20;
xt += cell_width * 3 / 10;
switch (attr.attr & (ATTR_SUBSCR | ATTR_SUPERSCR)) {
case ATTR_SUBSCR | ATTR_SUPERSCR:
yt += cell_height * 10 / 32; // 11 fits better but closer to subscr
break;
case ATTR_SUBSCR:
yt += cell_height * 13 / 32; // 14 looks better but at some clipping
break;
case ATTR_SUPERSCR:
yt += cell_height * 1 / 8;
break;
}
}
...
I wonder how that looks like. Did you test this? Have you any screenshots of this?
If you could get me a few escape sequences that I can echo in a prompt, I could try next time I'm in front of Windows. AFAIK Git Bash (which I definitely have installed) uses MinTTY under the hood.
@whisperity
You can uncomment these lines in test/decoration.sh:
# decoration 73 "Superscript"
# decoration 74 "Subscript"
# decoration 75 "Neither superscript nor subscript"
WinVer: Windows 10 Version 2004 (OS Build 19041.1165)
$ mintty -V
mintty 3.0.6 (x86_64-pc-msys)
© 2013/2019 Andy Koppe / Thomas Wolff
WinVer: Windows 10 Version 2004 (OS Build 19041.1165)
$ mintty -V mintty 3.0.6 (x86_64-pc-msys) © 2013/2019 Andy Koppe / Thomas Wolff
This looks reasonable. But is nothing that would be implemented trivially as it required passing some additional info to the glyph rasterizer. Let's see.
@whisperity Can you test and upload screenshot for this:
Combined SGR 73;74 results in small characters at normal position.
I'm not sure I'm combining them the right way. Should it be \033[73;74m? If so, it seems 73 takes precedence.
Superscript/subscript - request for information, plus "small text" feature request: https://github.com/mintty/mintty/issues/1171
Are there actually apps making use of this?
OTOH: I'm entirely not against having this implemented. The way wezterm is doing it (just offsetting vertically) looks definitely broken to me, the size should therefore be also adjusted, just like mintty is doing. That makes implementing it somewhat more challenging though.
FYI, XTerm recently released an update that repurposed the DECSGR sequence as a query for XTMODKEYS state, so now mintty has dropped support for DECSGR, and I suspect that wezterm and libvterm will do the same (for more info see https://github.com/mintty/mintty/issues/1171#issuecomment-1336174469 and https://github.com/mintty/mintty/issues/1189).
On the other hand, VTE has made it clear that they definitely won't support mintty's proprietary 73/74/75 SGR renditions, and also won't support XTerm's conflicting XTQMODKEYS query, so if they add subscript/superscript it's likely to be using the DECSGR sequences (see https://gitlab.gnome.org/GNOME/vte/-/issues/361#note_1176717 and https://gitlab.gnome.org/GNOME/vte/-/issues/2607#note_1617458).
You should also be aware the XTerm has now started using OSC 60 for a XTQALLOWED query sequence, which conflicts with Contour's OSC 60 usage (#162). I informed Thomas of this conflict along with the DECSGR conflict several weeks ago, and I think it's safe to assume by now that he's not going to back down.
One of his excuses was that he "didn't see it documented" (I did point out that it was documented in your contour info vt output), and the other was that "other developers generally add codes above 200" (again not true - I provided him with several examples of sub-200 OSC numbers used by other terminals).
On the other hand, VTE has made it clear that they definitely won't support mintty's proprietary 73/74/75 SGR renditions
Oh interesting. I'd like to know why. 🤔 (they wouldn't be my top prio anyways due to more pressing/important features & tasks anyways)
and also won't support XTerm's conflicting
XTQMODKEYSquery.
This is another huuuge topic for me. I'd like to implement an improved keyboard event transport protocol. There's the modkeys feature from xterm and kitty's. If I remember correctly, @gnachman at one point even told me that I should implement xterm's version because it's superior (I hope I'm not misleading bad remembering here). I wonder how that would conflict in a future keyboard protocol with GNOME's refusal to implement XTQMODKEYS - which, to me, sounds like it's needed for that one. (I haven't fully understood how xterm's improved keyboard proto works just yet).
You should also be aware the XTerm has now started using OSC 60 for a XTQALLOWED query sequence, which conflicts with Contour's OSC 60 usage (https://github.com/contour-terminal/contour/issues/162). I informed Thomas of this conflict along with the DECSGR conflict several weeks ago, and I think it's safe to assume by now that he's not going to back down.
WTF! Okay, granted, I did not publically announce OSC 60. But I think it's superior to what was there before, but ugh. Just because Thomas Dickey is ignoring something should not mean we should all jump as he pleases. Contour is young enough to justify protocol changes. Better earlier than later, but in the long run, I think we should find a fix for how we communicate VT protocol extensions and their number allocations.
But generally speaking, many thanks for raising this topic @j4james. I should improve github.com/contour-terminal/vt-extensions repo to include OSC 60 as well. I just recently created this repo to have a collective place of VT extensions (not necessarily to Contour exclusively! hint hint) 😄
One of his excuses was that he "didn't see it documented" (I did point out that it was documented in your contour info vt output) [...]
Okay, I think I can grasp your satisfaction wrt. communication very well. I'm feel for you, sorry.
Actually, contour info vt is listing OSC 60. And that list is generated programmatically. It'll list exclusively what is being implemented, never less, and nothing more.
I however considered adding more information for each VT sequence, but thought it's probably too much meta. Also, given that I'm not full-time working on my project (we all aren't, are we :) ).
I haven't had the time to force myself through HTML to create some nice documentary website for Contour just yet, I'm desperately hoping to find some web-dev that likes Contour enough to help me out there.
Okay, I think we went way beyond the actual topic of the original top-posting, but many thanks @j4james for your continued input. :)
EDIT: p.s.: found it at least in the changelog and more precise: https://github.com/contour-terminal/contour/blob/5e91e574c1853cfb6053a5645e7c02c14da85041/metainfo.xml#L479 ... not perfect, but i'll fix that for past and future exts.
On the other hand, VTE has made it clear that they definitely won't support mintty's proprietary 73/74/75 SGR renditions
Oh interesting. I'd like to know why.
Because there was already an existing standard for selecting those renditions via the the DECSGR sequences. At least until XTerm came along and decided it was going to use that sequence for something else. So it's understandable why VTE doesn't want to support the XTQMODKEYS sequence either.
I should also mention that there is another standard for superscript and subscript, which is the ANSI PLU and PLD sequences. That was actually my original suggestion to VTE about a year ago, but my impression at the the time was that they preferred to go with DECSGR.
I wonder how that would conflict in a future keyboard protocol with GNOME's refusal to implement
XTQMODKEYS.
Well they seem open to supporting the basic keyboard protocol - just not the XTQMODKEYS query. And my suggestion to them was that they could always support querying the XTMODKEYS state with a standard DECRQSS query. I haven't had any feedback regarding that proposal though.
Thomas Dickey is ignoring something should not mean we should all jump as he pleases.
My thoughts exactly. It's somewhat inevitable that there are going to be conflicts from time to time, because you can't expect every terminal to know what every other terminal is doing. But Thomas was informed within days of his release that there was a conflict - he could easily have backed out that change and used something else.
What really staggers me is that the three terminals that were already using DECSGR managed to convince themselves that it was somehow their fault that XTerm was conflicting with them, and so it was their responsibility to drop their support for DECSGR. 🤦♂️
On the other hand, VTE has made it clear that they definitely won't support mintty's proprietary 73/74/75 SGR renditions
Oh interesting. I'd like to know why.
Because there was already an existing standard for selecting those renditions via the the
DECSGRsequences. At least until XTerm came along and decided it was going to use that sequence for something else. So it's understandable why VTE doesn't want to support theXTQMODKEYSsequence either.
For some reason, I can't stop laughing at this show. Hmm... So I'm willing to get this implemented if we can get 3 (or so) TEs to agree on one of the possible ways to enable it.
I should also mention that there is another standard for superscript and subscript, which is the ANSI
PLUandPLDsequences. That was actually my original suggestion to VTE about a year ago, but my impression at the the time was that they preferred to go withDECSGR.
I'm also fine in going for PLU / PLD, if we ideally get mintty to move, too (as they're using the other way, it would be nice to minimize the divergence).
I wonder how that would conflict in a future keyboard protocol with GNOME's refusal to implement
XTQMODKEYS.Well they seem open to supporting the basic keyboard protocol - just not the
XTQMODKEYSquery. And my suggestion to them was that they could always support querying theXTMODKEYSstate with a standardDECRQSSquery. I haven't had any feedback regarding that proposal though.
Oh I am highly in favor of DECRQSS over the XT-version. I'd feel also more motivated to adopt XTMODKEYS then :)
Thomas Dickey is ignoring something should not mean we should all jump as he pleases.
My thoughts exactly. It's somewhat inevitable that there are going to be conflicts from time to time, because you can't expect every terminal to know what every other terminal is doing. But Thomas was informed within days of his release that there was a conflict - he could easily have backed out that change and used something else.
I would say he still can back out, in a future (soonish) patch. I am not aware of any apps actually using XTQMODKEYS nor XTQALLOWED. I tried hard searching the web. - What I found is this: https://fossies.org/linux/xterm/NEWS
To quote:
6 * add control sequences for reporting the current state of the 7 modified keys options (XTQMODKEYS) and allowed/disallowed 8 operations (XTQALLOWED), (prompted by discussion with Bram 9 Moolenaar).
I failed at finding out where that "discussion with Bram Moolenaar" must have happened. It would be nice to post-read their motivation behind and if there's any real use.
What really staggers me is that the three terminals that were already using
DECSGRmanaged to convince themselves that it was somehow their fault that XTerm was conflicting with them, and so it was their responsibility to drop their support forDECSGR. :man_facepalming:
:angry: :rage:
This is going to be a tough call, I know. But sincerely and objectively, I think we need to eventually deal with the fact, that we must life in a world without xterm. This time will(!) come. And I'm already curious to see how the TE dev community will act after that. I hope we'll not be thrown back into the 80s (as somebody else has put it to me recently)
While (of course) trying to preserve the past a bit (e.g. because people like you, but also Koichi, seem to care about), we must be able to look forward, a little bit more openly, more respectfully, and lesser everyone in his own world. (let's see whos going to roast me for this) :pizza: :cheese:
If I may chime in:
Breaking or violating older standards while being informed about it is not a bold move anymore, it is a dick move.
Not much more to say than - yes we will enter new 80s situation with breaking TE support into vendor flavors. xterm lasted for the last 20ys as a minimal support base, but we have this "oh well, idc much about the rest of the ecosystem" mindset already for quite some time now (also the reason why terminal-wg is a joke). Congratulations. Not.
So I'm willing to get this implemented if we can get 3 (or so) TEs to agree on one of the possible ways to enable it.
Well right now I think mintty, wezterm, and libvterm all support SGR 73/74/75, so that's already 3, but the problem with that choice is that VTE definitely won't support it. Then again, VTE hasn't made any real commitment to supporting superscript/subscript at all, so maybe it's not worth worrying about. However, if one day they do decide to implement DECSGR, that's guaranteed to create a split in the TE community because of how widely VTE is used.
Personally I'm not in any hurry to implement anything here, and I'm in agreement with VTE that we should be using a standard sequence for this when one already exists, so I'd be inclined to wait and see what they do. If they eventually decide to go with DECSGR, then that would be my choice too - I don't care if that conflicts with XTerm anymore. That said, I don't get the final say in what goes into Windows Terminal.
I failed at finding out where that "discussion with Bram Moolenaar" must have happened. It would be nice to post-read their motivation behind and if there's any real use.
I suspect this was likely a private email discussion. And I consider Bram just as much to blame in all of this, because he knew XTQMODKEYS conflicted with existing DECSGR usage. He was forced to patch the libvterm library used in vim so he could get XTQMODKEYS to take preference over the existing DECSGR implementation, so it's not like he can claim he didn't know about it.
@christianparpart If you think sub/superscript is important for you right now, imho the PLU/PLD might be a safe bet for now, until someone claims that for reporting the SP key state... :imp:
No seriously - I'd go with the ANSI versions first. The DECSGR thingy seems really outdated/superseeded, and I see no good story yet, why this should get revived from 40ys old printer manuals (seems it got not even mentioned in any terminal manuals by DEC either).
I don't care if that conflicts with XTerm anymore
Eventually that problem will solve itself anyways. I personally don't care that much about XTerm anymore myself. I do care about common sentiment however, for sure. No, super/sub-script isn't as important as it needs to be implemented ASAP, I can wait a bit, and also, I do not mind supporting PLU/PLD as well as DECSGR.
I'm not a big fan of artificially keeping features alive (just wanted to state that as a disclaimer), but for this one here, I actually do see some use. And since SGR 73/74/75 is already implemented by 3 TEs, maybe we can bring up this topic to those TEs at some point in the future and invite them for a discussion such that we can come to an agreement on how to deal with this in the future. (I like dreams).
That said, happy 4th advent, Christian.
FYI, the latest version of XTerm (patch 389) now has support for querying the state of XTMODKEYS with a standard DECRQSS sequence. Hopefully applications that were previously using the XTQMODKEYS query will now migrate to DECRQSS, and it'll eventually be safe to support the DEC SGR sequences again.