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
Am i the only one reading the question and thinking "Please keep freaking emojis out of my shell" ?
This is such a fun idea. I never expected the terminal to have this kind of retro way to “blow up” emojis. Seeing a whole row of giant faces honestly made it feel like the terminal had emotions. Now I kind of want to throw a giant warning emoji into a monitoring script. No way anyone’s ignoring that.
Great. A feature that makes Apple's default Terminal better than iTerm or WezTerm. Just what I didn't need!
> At least provided they aren't overused, just like colour.
Yeah. Right. Like that's going to happen.
I'd recommend folks to check-out https://ghostty.org if you haven't. It is fast, feature-rich and native!
The main author of Ghostty also wrote about how different terminals handle emojis https://mitchellh.com/writing/grapheme-clusters-in-terminals (2023)
Back in my day... They didn't have emojis in terminals.
The DEC GIGI (General Imaging Generator and Interpreter) aka VK100 was a cool color VT100 that had BASIC build in!
https://terminals-wiki.org/wiki/index.php/DEC_VK100
https://randoc.wordpress.com/2018/04/08/digital-equipment-de...
I have a friend who is into retrocomputing and has a daughter named Gigi and I would love to get her one!
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.
Large text didn't work at all on either of the two terminal emulators I normally use (guake/gnome terminal). Normally I use toilet/figlet for larger text.
That got me wondering, are there any figlet fonts that support a lot of emoji? Certain non-ascii characters are already pretty well supported.
My terminal doesn't even scale the text :(
If I make a terminal emulator, I do not want to support colourful emoji at any size. (There are a few other things I also would not want to implement, but also some things to do that other terminal emulators don't do.)
WezTerm appears to support upscaling, but I only get the first emoji printed - the combining part does not work.
Konsole handled both perfectly - emojis and the large text too. Large text is particularly mind-blowing to me, I think I have never seen it, and definitely not in scripts. But it looks like it could be mighty useful.
> Alternatively, you might not want to use literal 1970s technology and be interested that Kitty recently introduced a more modern way to get different sized text in a terminal.
Kittys “modern” way of doing it is still 1979s tech. Kitty just decided it would discard the standard escape sequences because of “reasons”.
Honestly, much as some of Kittys custom sequences have improved things, this particular sequence doesn’t.
This is a really cool little interaction, thanks for sharing!
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.
The much better question is: "Does it need to?"
And the follow up question: "What do emojis add to anything I'd read on the terminal?"
This is exposing so many bugs in konsole
As big as I want: imgcat empji.jpg
Can we just move past the plain text nature of terminals and move to fully graphical terminals, please? Plan9 did this in 1995, for crying out loud.
Terminals would still run command line programs, but also graphical programs, or simply display some graphical elements and you’ll still do a lot of typing, but graphics won’t be shoehorned in as they are now.
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.
The issue with the emoji, at least in their current depictions, is that they are guaranteed to be higher in visual hierarchy (among the few things of undying relevance that we were taught in university) than any surrounding text. They stand out thanks to their different nature and a lot of visual complexity (intricate features).
Good visual hierarchy means you end up looking first at what is important. Good visual hierarchy sets correct context.
Bad visual hierarchy adds mental overhead. Bad visual hierarchy means that any time you look, even when you don’t consciously realize it, you end up scanning through hierarchy offenders, discarding them, then getting to the important part, and re-acknowledging offenders when it comes to them in appropriate context. This can happen multiple times: first for the screen as a whole, then when you focus on a smaller part, etc. As we encounter common visual hierarchy offenders more and more often, we train ourselves to discard them quicker, but it is never completely free of cost.
There are strategic uses for symbols in line with visual hierarchy principles. For example, using emoji as an icon in an already busy GUI is something I do as well.
However, none of those apply in terminal’s visual language of text and colours, and unlike a more or less static artifact fully under designer’s control (like a magazine or a GUI) in a fluid terminal screen where things shift around and combine in different ways it is almost impossible for software author to correctly predict what importance what has to me.
Those CLI tool authors who like to signify errors with bright emoji: have you thought that my screen can be big, and after I ran your program N times troubleshooting something there can be N bright red exclamation marks on my screen, N-1 of which are not even remotely close to where the message of interest is? have you thought that your output can coexist in a multiplexer with output from another program, which I am more interested in? should other programs compete for attention with brighter emojis? and so on.
As to joyful touches, which are of course appreciated, those can be added with the old-style text-based emoticons.