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? and so on.
As to joyful touches, which are of course appreciated, those can be added with the old-style text-based emoticons.
b0a04gl · 5h 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 · 3h 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.
inetknght · 2h ago
> This basically creates a software maintenance burden out of aether.
So... basically all modern software?
crackalamoo · 5h 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 · 3h 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 ...
As fallback, you can also just emit the character and see how far the cursor advanced via CSI 6n (try printf '\x1b[6n')
o11c · 2h ago
Doing that adds a lot of round trips, so you still really need to do the initial estimate.
(also, probing for whether the terminal actually supports various features is nontrivial. At startup you can send the basic "identify the terminal" sequences (there are 2) and check the result with a timeout; subsequently you can make a request then follow it with the basic terminal id to see if you actually get what you requested. But remember you can get arbitrary normal input interspersed.)
Joker_vD · 2h ago
The main problem is not even if the terminal itself can track the grapheme width "correctly". It's a) the fonts suck; b) does the terminal user tracks the width correctly?
About a): some fonts have the glyphs for e.g. the playing cards block that are 1.5 columns wide even though the code points themselves are defined to be Narrow. How do you render that properly? Then there are variation selectors: despite what some may think, they don't affect the East Asian Width of the preceding code point, so whether you print "\N{ALEMBIC}\N{VARIATION SELECTOR-15}" or "\N{ALEMBIC}\N{VARIATION SELECTOR-16}", it still, according to wcwidth(), takes 1 column; but fonts have glyphs that are, again, 1.5 and 2 cells wide.
And then there is the elephant in the room problem b) which is management of cursor position. But the terminal, and the app that uses the terminal need to have exactly the same idea of where the cursor is, or e.g. readline can't reliably function, or colorful grep output. You need to know how many lines of text you've output (to be able to erase them properly), and whether the cursor is at the leftmost column (because of \b semantics) or at the rightmost column (because xenl is a thing) or neither. And no, requesting the cursor position report from the terminal doesn't really work, it's way too slow and it's interspersed with the user input.
The TUI paradigm really breaks down completely the moment the client is unsure how its output affects the cursor movement in the terminal. And terminals don't help much either! Turning off autowrap is mostly useless (the excess output is not discared, it overwrites the rightmost column instead), the autobackwrap (to make \b go to the previous line from the leftmost column) is almost unsupported and has its own issues, there is no simple command/escape sequence to go to the rightmost column... Oh, and there is xenl behaviour, which has many different subtle variations, and which original VT100 didn't even properly have despite what terminfo manual page may tell you — you can try it with the terminal emulator mentioned in TFA for yourself: go to setup, press 4, 5, move with right arrow to the block 3 and turn the second bit in it on by pressing 6 so it looks like "3 0100", exit setup (what you did is put the temrinal into the local mode so you can input text to it from your keyboard and turned the autowrap on), then do ESC, print "[1;79Hab", do LINE-FEED, print "cd" — you'll see that there is an empty line which shouldn't really be there, and it is not there if you do e.g. printf "\033[1;1Hxx\033[1;79Hab\ncd" on xterm (ironic, given how xterm's maintainer prides themself on being very faithful to original VT100 behaviour) or any other modern terminal.
account42 · 1h ago
It's more down to whatever monospace font the terminal uses not having those emojis and the (likely proportional) font they come from giving them a different width.
Aziell · 1h ago
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.
p4cmanus3r · 2h ago
Back in my day... They didn't have emojis in terminals.
gylterud · 1h ago
U+263A entered Unicode in 1993, afaik. Plan9 had utf8 support in the terminal back then!
Findecanor · 19m ago
Single code point, monochrome and single space. So it didn't need to be handled differently than any other non-ASCII character.
BTW, it is emitted with the sequence `Compose` `:` `)` (if you have Compose-key support installed+enabled)
uncircle · 2h ago
Really? So how did you understand each other, grandpa?
DonHopkins · 2h ago
I heard they used to feel each others faces with their hands, like Hellen Keller, or with their mouths, like Mr. Peepers.
When was your day? Emoticons have been used in terminals since 1982
account42 · 1h ago
Emoticons are not the same as emojis. For one they allow for more expression or personal style by having different variants, e.g. :-) vs :) or for absolute maniacs: (:
They are also not limited to what some consortium and a couple of megacorporations think you should be able to express.
oneeyedpigeon · 58m ago
They also lack semantics. There are downsides as well as up.
account42 · 49m ago
Usage rather than specifications determine semantics and due to the points in my previous post those often disagree for Unicode emojis.
oneeyedpigeon · 28m ago
I'm glad you recognise the value of usage when it comes to emoticons vs. emoji...
arccy · 26m ago
emoji lack clear semantics too, consider the eggplant.
nottorp · 3h ago
> At least provided they aren't overused, just like colour.
Yeah. Right. Like that's going to happen.
oneeyedpigeon · 1h ago
Great. A feature that makes Apple's default Terminal better than iTerm or WezTerm. Just what I didn't need!
duped · 3h 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.
account42 · 1h ago
This has nothing to do with UTF-8 which doesn't and shouldn't care about anything beyond mapping bytes to code points.
But even for adding it to Unicode, your proposal would make text stateful (even over long distances) which is a really bad idea.
CamouflagedKiwi · 1h ago
Combining characters have already made Unicode text stateful.
Although I agree that encoding length hints into it seems like a bad idea - it creates an opportunity for the encoding to disagree with the reality of the text. You need _some_ way of handling it if it says that the next grapheme cluster is 4 characters long but it's actually only three.
> 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.
the_gipsy · 1h ago
It does improve because IIRC support for the old sequence cannot be reliably detected.
Ignoring the escape sequences a terminal doesn't understand, or doesn't want to deal with is explicitly allowed (required, even) by the ECMA-48 standard. And DECHDL is not "standard" by any means.
panki27 · 2h ago
WezTerm appears to support upscaling, but I only get the first emoji printed - the combining part does not work.
phito · 4h ago
My terminal doesn't even scale the text :(
yonatan8070 · 1h ago
What's your terminal?
dima55 · 3h ago
Mine too. This is a feature :)
liamkearney · 4h ago
This is a really cool little interaction, thanks for sharing!
yla92 · 3h ago
I'd recommend folks to check-out https://ghostty.org if you haven't. It is fast, feature-rich and native!
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)
cyberge99 · 2h ago
As big as I want: imgcat empji.jpg
mmastrac · 5h 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 · 3h 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 · 3h 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 · 3h 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.
kergonath · 41m ago
> Rendering [failed] in red and [passed] in green would achieve the same. It's not emoji vs text. It's color vs no color.
True, but my prompt is full of colour ASCII characters so emoji stand out. And also, emoji fare better than escape codes when they pass through pipes and stuff.
tetha · 1h ago
And shapes, though you can get that with some ASCII art as well.
I've had a few scripts some time ago that took a long time to run, so I wanted a progress indicator I could see from across the room - that way I could play some guitar while monitoring the computer doing stuff in the evening.
Hence, the log messages got prefixed with tags like:
> ]
>> ] # normal progress
/!\/!\] # it had to engage in a workaround
x_x ] # if it had to stop.
warkdarrior · 3h 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 · 4h 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 · 5h 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.
kergonath · 3h ago
Yeah. Please don’t do that.
utf_8x · 2h ago
Oh god, please don't give them ideas
liamkearney · 4h ago
What doesn’t justify shipping chromium these days?
dgl · 3h 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)
I have a friend who is into retrocomputing and has a daughter named Gigi and I would love to get her one!
LtWorf · 3h ago
This is exposing so many bugs in konsole
sebtron · 2h 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.
hnlmorg · 2h ago
I’m the same. I hate emojis anywhere that is intended to be informative reading. Whether it is terminal output, markdown documents (even titles), git commit messages, etc.
I get they bring people a little bit of joy, but as a dyslexic who likely also has ADHD, they bring me unnecessary distractions and visual clutter.
The only time I like emojis in a formal setting is when used in Slack to denote a thread (the thread/sewing emoji).
No comments yet
Springtime · 2h 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).
account42 · 2h ago
I really hate that Unicode retroactively made some pre-existing smileys into colored-by-default emojis.
kergonath · 1h ago
> 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.
This is mostly cultural, though. Some people are used to this.
magackame · 1h ago
Noto Emoji has all emoji as monochrome outlines.
bigstrat2003 · 2h ago
Emojis do not belong in the CLI, ever. Hell, I personally think they shouldn't be in Unicode at all (as they are not text), but that ship has long since sailed unfortunately.
account42 · 1h ago
The argument for emojis in Unicode was that existing chat protocols had them. But I don't buy that argument since many chat protocols also supported custom smileys which Unicode doesn't. Trying to standardize creative expression is a mistake IMO.
juliangmp · 1h ago
I'm fine with them used sparingly in documentation, but in actual terminal output they mostly don't get rendered properly so I'd stick to nerd fonts if I want "icons" of any kind.
graemep · 1h ago
I think they are overused everywhere. Most annoyingly as a workaround to put pictures in what should be text - email subject lines for example.
I like coloured text, and I like TUIs. To be fair, nothing I use has noticeable emojis. I am not really bothered about enhanced terminals - I would rather keep terminals simple and use a GUI if I need more complex presentation.
skerit · 2h ago
I'm sorry, I really like it. When used in titles & subtitles, I find it makes it a lot more pleasant to read for me.
dkdbejwi383 · 1h ago
I’m not sure why you got downvoted for this. Is HN turning into reddit where downvote means “I have a different opinion”?
bluebarbet · 1h ago
Without activist moderation, that would appear to be the default outcome. Most humans seem to have an urge to stamp on dissonant opinions. Unfortunately.
lgeorget · 2h ago
I like them when they're used as bullet points in lists for instance. Just like we've always used small icons of phones and envelopes in contact information boxes/business cards to identify the fields at a glance.
pknerd · 2h ago
> Am I the only one who actually dislikes the recent trend of putting emojis everywhere in CLI tools?
No.
adastra22 · 2h ago
It was cute before it was everywhere thanks to LLMs.
uncircle · 2h ago
It was already annoying before LLMs got popular. Now it’s gotten out of hand <rocket emoji>
Agreed. Emojis are even more prominent than colors, so they should be very sparingly used. I'm not against the use of emojis in terminals per se (regardless of my opinion of the very introduction to emojis in Unicode), but they are now too many to be visually ignored.
nickdothutton · 2h ago
Unless the emoji is serving the purpose of a button or icon, then at the CLI (and TUI) I prefer not to see them. A good example (IMO) of their proper use would be as a traffic light indicator for something.
Always consider the output of your program may be used as the input for another program to paraphrase klt.
LeoPanthera · 2h ago
You are never the only one.
account42 · 1h ago
You are the only one who doesn't understand that not all questions are meant literally though.
DonHopkins · 2h ago
I dislike putting ASCII characters in CLI tools and logs and think they should be PURE EMOJI! [ wink emoji ;) ]
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? and so on.
As to joyful touches, which are of course appreciated, those can be added with the old-style text-based emoticons.
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.
So... basically all modern software?
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
(also, probing for whether the terminal actually supports various features is nontrivial. At startup you can send the basic "identify the terminal" sequences (there are 2) and check the result with a timeout; subsequently you can make a request then follow it with the basic terminal id to see if you actually get what you requested. But remember you can get arbitrary normal input interspersed.)
About a): some fonts have the glyphs for e.g. the playing cards block that are 1.5 columns wide even though the code points themselves are defined to be Narrow. How do you render that properly? Then there are variation selectors: despite what some may think, they don't affect the East Asian Width of the preceding code point, so whether you print "\N{ALEMBIC}\N{VARIATION SELECTOR-15}" or "\N{ALEMBIC}\N{VARIATION SELECTOR-16}", it still, according to wcwidth(), takes 1 column; but fonts have glyphs that are, again, 1.5 and 2 cells wide.
And then there is the elephant in the room problem b) which is management of cursor position. But the terminal, and the app that uses the terminal need to have exactly the same idea of where the cursor is, or e.g. readline can't reliably function, or colorful grep output. You need to know how many lines of text you've output (to be able to erase them properly), and whether the cursor is at the leftmost column (because of \b semantics) or at the rightmost column (because xenl is a thing) or neither. And no, requesting the cursor position report from the terminal doesn't really work, it's way too slow and it's interspersed with the user input.
The TUI paradigm really breaks down completely the moment the client is unsure how its output affects the cursor movement in the terminal. And terminals don't help much either! Turning off autowrap is mostly useless (the excess output is not discared, it overwrites the rightmost column instead), the autobackwrap (to make \b go to the previous line from the leftmost column) is almost unsupported and has its own issues, there is no simple command/escape sequence to go to the rightmost column... Oh, and there is xenl behaviour, which has many different subtle variations, and which original VT100 didn't even properly have despite what terminfo manual page may tell you — you can try it with the terminal emulator mentioned in TFA for yourself: go to setup, press 4, 5, move with right arrow to the block 3 and turn the second bit in it on by pressing 6 so it looks like "3 0100", exit setup (what you did is put the temrinal into the local mode so you can input text to it from your keyboard and turned the autowrap on), then do ESC, print "[1;79Hab", do LINE-FEED, print "cd" — you'll see that there is an empty line which shouldn't really be there, and it is not there if you do e.g. printf "\033[1;1Hxx\033[1;79Hab\ncd" on xterm (ironic, given how xterm's maintainer prides themself on being very faithful to original VT100 behaviour) or any other modern terminal.
BTW, it is emitted with the sequence `Compose` `:` `)` (if you have Compose-key support installed+enabled)
https://www.youtube.com/watch?v=QV2kaJ5_8PU
They are also not limited to what some consortium and a couple of megacorporations think you should be able to express.
Yeah. Right. Like that's going to happen.
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.
But even for adding it to Unicode, your proposal would make text stateful (even over long distances) which is a really bad idea.
Although I agree that encoding length hints into it seems like a bad idea - it creates an opportunity for the encoding to disagree with the reality of the text. You need _some_ way of handling it if it says that the next grapheme cluster is 4 characters long but it's actually only three.
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.
https://github.com/benjajaja/mdfried utilizes the new protocol and an image render fallback.
The main author of Ghostty also wrote about how different terminals handle emojis https://mitchellh.com/writing/grapheme-clusters-in-terminals (2023)
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.
True, but my prompt is full of colour ASCII characters so emoji stand out. And also, emoji fare better than escape codes when they pass through pipes and stuff.
I've had a few scripts some time ago that took a long time to run, so I wanted a progress indicator I could see from across the room - that way I could play some guitar while monitoring the computer doing stuff in the evening.
Hence, the log messages got prefixed with tags like:
[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
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!
I get they bring people a little bit of joy, but as a dyslexic who likely also has ADHD, they bring me unnecessary distractions and visual clutter.
The only time I like emojis in a formal setting is when used in Slack to denote a thread (the thread/sewing emoji).
No comments yet
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).
This is mostly cultural, though. Some people are used to this.
I like coloured text, and I like TUIs. To be fair, nothing I use has noticeable emojis. I am not really bothered about enhanced terminals - I would rather keep terminals simple and use a GUI if I need more complex presentation.
No.
Emojis in repos and CLI tools is the textual counterpart to the soulless Alegria art style: https://en.m.wikipedia.org/wiki/Corporate_Memphis