Back in my day... They didn't have emojis in terminals.
sebtron · 19m ago
Am I the only one who actually dislikes the recent trend of putting emojis everywhere in CLI tools? I am ok with red and yellow text for errors and warning, and I can stand green for success (though I find it useless), but emoji's are just distracting.
Springtime · 13m ago
I also find fully rendered/colored emojis distracting even in repo readmes because I feel they give off a casual chat messaging vibe, since before colored emojis became part of Unicode proper they were exclusively used for chat messengers.
There's a Unicode sequence that tries to use a monochrome glyph instead if it's supported which I prefer as it's more in keeping with the rest of the text (though an issue with some of those variants is legibility at small sizes/PPI).
LeoPanthera · 18m ago
You are never the only one.
adastra22 · 13m ago
It was cute before it was everywhere thanks to LLMs.
b0a04gl · 3h ago
emoji width bugs mostly come down to how terminals interpret Unicode's "grapheme clusters" vs "codepoints" vs "display cells". emoji isn't one codepoint - it's often multiple joined by zero-width joiners, variation selectors, skin tone modifiers. so the terminal asks wcwidth(), gets 1 or 2, but the actual glyph might render wider or combine into a single shape.
some emoji even change width depending on font. family emoji is like 7 codepoints, shows up as one glyph. most terminals don't track that. they just count codepoints and pray.
unless terminal is using a grapheme-aware renderer and syncs with the font's shaping engine (like freetype or coretext), it'll always guess wrong. wezterm and kitty kinda parse it right often
duped · 47m ago
Why do you need to sync with the shaping engine?
TBH grapheme clusters are annoying but day 1 learning material for a text display widget that supports beyond ascii. It honestly irks me how many things just fuck it up, because it's not an intractably hard problem - just annoying enough to be intractable for people that are lazy (*).
(*) the actually hard problem with grapheme clusters is that they're potentially unbounded in length and the standard is mutable, so your wcwidth() implementation needs to be updated along with standards to stay valid, particularly with emoji. This basically creates a software maintenance burden out of aether.
crackalamoo · 2h ago
Yeah, unfortunately I feel like despite all the advances in Unicode tech, my modern terminal (MacOS) still bugs out badly with emojis and certain special characters.
I'm not sure how/when codepoints matter for wcwidth: my terminal handles many characters with more than one codepoint in UTF-8, like é and even Arabic characters, just fine.
o11c · 42m ago
`wcwidth` works by assigning all codepoints (strictly, code units of whatever size `wchar_t` is on your system, but thankfully modern Unixen are sane) a width of -1 (error), 0 (combining), 1 (narrow), or 2 (wide).
`wcswidth` could in theory work across multiple codepoints, but its API is braindead and cannot deal with partial errors.
This is all from the perspective of what the application expects to output. What the terminal itself does might be something completely different - decomposed Hangul in particular tends to lead to rendering glitches in curses-based terminal programs.
This is also different from what the (monospace) font expects to be rendered as. At least it has the excuse of not being able to call the system's `wcwidth`.
Note that it is always a mistake to call an implementation of `wcwidth` other than the one provided by the OS, since that introduces additional mismatches, unless you are using a better API that calculates bounds rather than an exact width. I posted an oversimplified sketch (e.g. it doesn't include versioning) of that algorithm a while back ...
Which however does not support DECDHL. So if you want to try what this post is about, Ghostty is not the right terminal. (It's great in general though)
duped · 37m ago
In my fever dreams of maintaining utf8 supporting text widgets that work and never need to be updated, there's a zero-width whitespace grapheme cluster that represents the number of codepoints in the next grapheme cluster if they're different from the previous.
The situation today is basically the same as null terminated C strings. Except worse, because you can define that problem and solve it in linear time/space without needing to keep an up to date list of tables.
WezTerm appears to support upscaling, but I only get the first emoji printed - the combining part does not work.
nottorp · 23m ago
> At least provided they aren't overused, just like colour.
Yeah. Right. Like that's going to happen.
phito · 1h ago
My terminal doesn't even scale the text :(
dima55 · 37m ago
Mine too. This is a feature :)
liamkearney · 1h ago
This is a really cool little interaction, thanks for sharing!
mmastrac · 2h ago
I'd be happy if we could get terminals to agree on how wide the warning triangle emoji renders. The emoji are certainly useful for scripts, but often widths are such a crapshoot. I cannot add width detection to every bash script I write for every emoji I want to use.
If only there was a standards body that could perhaps spec how these work in terminals.
a5c11 · 1h ago
Or you could just rely on the ordinary, fixed-width font available in every terminal? I mean, what do you need emojis for in a bash script?
kergonath · 50m ago
Emoji are good to highlight information. A red cross stands out in a list of green ticks much better than a [failed] among the [passed].
gapan · 32m ago
> Emoji are good to highlight information. A red cross stands out in a list of green ticks much better than a [failed] among the [passed].
Rendering [failed] in red and [passed] in green would achieve the same. It's not emoji vs text. It's color vs no color.
warkdarrior · 1h ago
And, frankly, why even bother with lower-case characters? Upper case is plenty good -- it was good enough for the VT05, it should be good enough for your laptop.
noisy_boy · 1h ago
What a coincidence that I spent a good portion of time trying to deal with the warning triangle emoji and see your comment today. Incidentally the info and green ticks are not so bad. Wonder why that specific one has width issues.
charcircuit · 2h ago
You could ship a terminal with your script. This is how apps like Slack deal with inconsistent handling of standardized content by shipping an embedded chromium.
utf_8x · 10m ago
Oh god, please don't give them ideas
liamkearney · 1h ago
What doesn’t justify shipping chromium these days?
dgl · 1h ago
The ChromeOS terminal (hterm[1]) is actually a pretty good terminal, so even a terminal might justify a browser context. Blink[2] on iOS for example uses it.
[1]: https://hterm.org/ (although in the way they do Google seems to have lost interest in updating that site and the GitHub repo, there's still fixes in the upstream Chromium repo)
There's a Unicode sequence that tries to use a monochrome glyph instead if it's supported which I prefer as it's more in keeping with the rest of the text (though an issue with some of those variants is legibility at small sizes/PPI).
some emoji even change width depending on font. family emoji is like 7 codepoints, shows up as one glyph. most terminals don't track that. they just count codepoints and pray.
unless terminal is using a grapheme-aware renderer and syncs with the font's shaping engine (like freetype or coretext), it'll always guess wrong. wezterm and kitty kinda parse it right often
TBH grapheme clusters are annoying but day 1 learning material for a text display widget that supports beyond ascii. It honestly irks me how many things just fuck it up, because it's not an intractably hard problem - just annoying enough to be intractable for people that are lazy (*).
(*) the actually hard problem with grapheme clusters is that they're potentially unbounded in length and the standard is mutable, so your wcwidth() implementation needs to be updated along with standards to stay valid, particularly with emoji. This basically creates a software maintenance burden out of aether.
I'm not sure how/when codepoints matter for wcwidth: my terminal handles many characters with more than one codepoint in UTF-8, like é and even Arabic characters, just fine.
`wcswidth` could in theory work across multiple codepoints, but its API is braindead and cannot deal with partial errors.
This is all from the perspective of what the application expects to output. What the terminal itself does might be something completely different - decomposed Hangul in particular tends to lead to rendering glitches in curses-based terminal programs.
This is also different from what the (monospace) font expects to be rendered as. At least it has the excuse of not being able to call the system's `wcwidth`.
Note that it is always a mistake to call an implementation of `wcwidth` other than the one provided by the OS, since that introduces additional mismatches, unless you are using a better API that calculates bounds rather than an exact width. I posted an oversimplified sketch (e.g. it doesn't include versioning) of that algorithm a while back ...
https://news.ycombinator.com/item?id=43851532
The main author of Ghostty also wrote about how different terminals handle emojis https://mitchellh.com/writing/grapheme-clusters-in-terminals (2023)
The situation today is basically the same as null terminated C strings. Except worse, because you can define that problem and solve it in linear time/space without needing to keep an up to date list of tables.
Yeah. Right. Like that's going to happen.
If only there was a standards body that could perhaps spec how these work in terminals.
Rendering [failed] in red and [passed] in green would achieve the same. It's not emoji vs text. It's color vs no color.
[1]: https://hterm.org/ (although in the way they do Google seems to have lost interest in updating that site and the GitHub repo, there's still fixes in the upstream Chromium repo)
[2]: https://blink.sh