~ecs/ecs.d2evs.net

80df3272f89c1790a4bb5f7f68af5577678f3236 — Ember Sawady a month ago 48f851d ecs.d2evs.net
terminals bad
1 files changed, 25 insertions(+), 1 deletions(-)

R _drafts/2024-03-15-terminals-bad.gmi => posts/2024-05-27-terminals-bad.gmi
R _drafts/2024-03-15-terminals-bad.gmi => posts/2024-05-27-terminals-bad.gmi +25 -1
@@ 22,4 22,28 @@ yep! text is really quite simple like that

... wait oops sorry i got mixed up it's the opposite of the thing i said

so afaik there's not a whole lot of effort that's been put into standardizing this sort of thing. there're some areas we'll get to later where terminals tend to do the Wrong Thing, but at least that Thing has a pretty consistent consensus between everyone on what the standard behavior is. this is not one of those cases.
so afaik there's not a whole lot of effort that's been put into standardizing this sort of thing. there're some areas we'll get to later where terminals tend to do the Wrong Thing, but at least that Thing has a pretty consistent consensus between everyone on what the standard behavior is. this is not one of those cases

unicode defines a property called "east asian width", which is mostly just for marking cjk characters that're square rather than rectangular, and which doesn't handle emojis correctly. the historically-standard way of doing this has been to calculate text width on a per-codepoint level, which is definitely incorrect. foot does this but limits it to 2, which is more correct (though i'm not sure if it's Actually correct)

as a bonus, any changes in this algorithm which aren't reciprocated on both sides of the terminal protocol can and will lead to cursor desyncs. the only way that i know of to build a unicode-robust program which doesn't rely solely on the terminal's built-in text placement involves the Worst hacks

=> /posts/2024-02-13-madeline.gmi a description of said hacks

## ok sure, so "character" is a messed-up concept. but surely the "2d grid" part is fine, right?

nope! it's completely impossible for terminals to use non-monospace fonts because of this. there are some benefits to a monospace font in some contexts, but forcing everyone to use them all the time is... not optimal

as a bonus, modern text rendering has given up entirely on the assumption that text can be coerced into a 2d grid of any sort, which means that when we try to fit text back into that box, we stop being able to rely on any widely-used algorithms for text width in this context. joy.

## alright, so characters are messed up, and 2d grids are messed up, but surely so long as the characters do happen to be the same width everything will work out?

nope! terminals completely break with rtl text, and while this is a bit less inherent to the fundamental building blocks of how terminals work, in practice fixing it would require rewriting the text-rendering parts of every single tui program in existence, on top of quite a bit of work to fix cli programs without forcing them to start thinking about text rendering in too much detail

## ugh, that sucks. how can we fix it?

honestly i don't think we can, and even if we can, i'm not sure if it's worth it. terminals suck for a bunch of other reasons in addition to their poor unicode handling, and i'd much rather see a wholesale replacement for them which tries to keep the good parts without being shackled to backwards-compatibility with hardware from the '50s

and there are good parts of terminals, to be clear. small cli programs are really easy to write without having to think about the interface, even if that default interface isn't ideal, and i'd really like to see something which can keep that programmer-ease-of-use for simple cases

i also rather like plan9's approach to this: windows can have both text and pixels written to them, and text mode has none of the complexity that's required to be able to implement fullscreen programs in it. things which look and feel like tui programs are instead just drawing directly to the same window that until recently had a shell running in it, and because of this they aren't limited to a monospace grid of unicode characters. i would, however, like to see the text mode expanded a little bit from what plan9 has in order to better accommodate keyboard-only usage