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
crackalamoo · 1h 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.
phito · 17m ago
My terminal doesn't even scale the text :(
LtWorf · 6m ago
This is exposing so many bugs in konsole
liamkearney · 28m ago
This is a really cool little interaction, thanks for sharing!
mmastrac · 1h 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 · 10m 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?
warkdarrior · 6m 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 · 42m 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 · 1h 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.
liamkearney · 29m ago
What doesn’t justify shipping chromium these days?
dgl · 10m 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)
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
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.
If only there was a standards body that could perhaps spec how these work in terminals.
[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