alt Hacker NewsA much better alternative to this would be to for more terminal emulators to implement overstrike mode (DECSET 20, as available on the VK100). That way you could just draw border characters over existing text cells to achieve the same thing.
Unfortunately mintty is the only terminal emulator I'm aware of which supports overstrike [0], as this would open up a world of new possibilities for TUI apps if more widely supported.
[0] https://github.com/mintty/mintty/wiki/CtrlSeqs#overstrike
Replies
Overstrike is underrated!
I've really enjoyed using it on paper: https://hughpyle.com/ASR33/
I'm iffy about that. If you copy/dump text out of a terminal, what characters do you get for the doublestruck cells?
Plus, just complexity wise, I'd much rather just have a DCS sequence to draw vector lines like the article's suggestion than first send all the borders then home the cursor, send the overstrike sequence, send all the content, send the overwrite sequence. That has so many more places where a session gets trashed by accidentally sending the wrong control character.
I always find it somewhat amusing that most modern terminal emulators don't actually do a very good job of emulating terminals. IIRC Windows Terminal supports a lot of DEC commands that most of the terminal emulators on Linux don't!
I’m not against overstrike, but I can think of one drawback of that solution: it becomes significantly harder to have rounded corners with a filled interior.
But I’m not trying to argue for nor against either solution.
Huh, I'm not sure whether it is the same protocol, I know of this: https://vtdn.dev/docs/sgr/sgr-overline
The syntax is:
CSI 53 m SGR 53 — Overlined CSI 55 m SGR 55 — Not overlined
which is much more different than mitty's Control Sequence, but supports much more emulators
More terminal emulators should implement Tek4010 mode and just draw vectors everywhere.
The better alternative to most of this is to use a different display protocol, one that gives you pixel-level control, if you want pixel-level control.
There's some downsides to this - I can't recall where I called this out off the top of my head, but this also adds a bunch more things that that wouldn't do that are covered in the spec.
Expecting Terminal Emulators to support overstrike is a high bar even many text editors don't even support strikethrough. Would love to see it though
Overstriking support might be nice, but it wouldn’t help much for this use–case.
A considerably less archaic and more generally useful way would be for Unicode to add border-drawing given that the concept of composing several codepoints to the same glyph is already there and ubiquitous. You’d just need 2^4=16 new codepoints.