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.

▲

graypegg 13 hours ago | parent | next [-]

Unicode is a lot more concerned with what a character means vs how it displays. The box drawing characters that have codepoints are there because they were part of some device's proprietary text encoding, so it's put in a codepage somewhere so a document from that device could be used on something else given it gets converted to unicode.

Pretty unlikely they'd be into adding a new ZWJ pattern for bordering characters since it's awful given unicode's main goal is interoperability. If you copy text out of your terminal, those characters come with it and probably won't render correctly in non-terminal applications (which don't have monospaced text cells), so you'll just see the ? missing character symbol between every letter. (Possibly overstruck onto the previous character depending on handling for the ZWJ.)

I guess the other way to look at this would be "should the background colour be a unicode ZWJ pattern?"... probably not. The border (and colour) is a property of the terminal cell rather than the actual characters IMO. It's not like `X + ZWJ + LEFT-BORDER` has any unique encoded meaning. Cell attributes like the article is talking about IS the less archaic way of doing this. ZWJ patterns are a lot more archaic and cause a lot more issues. Overstrike is fine, if it's being down with cell attributes (meaning, moving the cursor overtop of a cell, and stamping a new character on it instead of replacing it. Exactly how mintty does it.)

▲

lenkite an hour ago | parent [-]

> Unicode is a lot more concerned with what a character means vs how it displays

This was only true before emojis. Unicode introduced specific code points purely to alter visual display, such as skin-tone modifiers, etc. Now that the mission was already diluted for emo-fluff, you might as well add actually useful fluff.

	▲	graypegg 22 minutes ago \| parent [-]
		Nahhh, they refuse a LOT of emoji proposals specically because they're just asking for a specific image. Here's that graveyard: https://unicode.org/emoji/emoji-proposals-status.html The ones they DO let through, must have some sort of useful distinction in meaning to be given a code point(s). It can't just be useful as a little image of a thing. It has to provide some sort of linguistic concept that extends the emoji... language? https://unicode.org/emoji/proposals.html#factors_inclusion The skintone modifiers are meaningful because it can look more like someone you're talking about. "S with a left border" isn't disambiguating any sort of meaning from "S with a bottom and right border".

▲

joshka 5 hours ago | parent | prev | next [-]

This is not as bad an idea as it would seem, but it's never going to happen with Unicode. It could reasonably happen with a combination of NerdFonts / private area shenanigans + cell rendering on the terminal side of this to handle it.

It solves the z-index problem neatly for an individual cell as you just render in order (first underneath, second over the top). But it doesn't solve the order for adjacent cells - borders that lie between cells. At least not easily. Not an insurmountable problem.

Some perspective if you're unaware. Fonts have the unicode line drawing characters, but fonts don't align super well and so a good terminal will draw those characters with line drawing algorithms instead of as a font. I've got a WIP PR that I need to land in VSCode's that pulls in xtermjs and ghostty's line drawing stuff so that it fixes up all the existing gaps on that as an example of this problem.

▲

binarymax 16 hours ago | parent | prev [-]

Oh like a diacritic? Good idea.

	▲	Sharlin 16 hours ago \| parent [-]
		Yep. And actually you’d only need four codepoints (per line style) because you could just chain them to get a line on more than one edge.