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 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).
On top of that, there are only very few emojis that can be read properly at the same size of the current line height. It works for a few simplified faces and symbols, but that's it.
The fact that emoji fonts override the font color rendering is an aggravating factor. I don't want text to change color behind my choice (it SUCKS with customized color themes).
They feel like a punch in the face to me when I'm reading documentation or even worse when reading code.
Sadly, it's really hard to avoid them nowdays. I'm using a few lisp scripts with emacs to translate the common ones back to ascii for rendering.
I can point out that "Noto Emoji" is a b/w version of Noto Color Emoji, which contains a MUCH more suitable version of emojis that can be used in running text. As noted before, it's only a partial solution as I find most emojis are still not readable when scaled at the same size as the text and when simplified sometimes they also lose the original meaning (just use the damn word dammit!). But at least they don't override the color. On linux, you can force a font substitution with fontconfig to force the b/w version whenever color-emoji is used and can't be customized.
No.
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.
Emojis in repos and CLI tools is the textual counterpart to the soulless Alegria art style: https://en.m.wikipedia.org/wiki/Corporate_Memphis
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.
I’m also of an age where emojis are more distracting than informative, but I notice younger colleagues use them liberally and with significant information value.
Like if I were to write three bullets about the results of an experiment, I would use three actual bullet points for maybe describing the hypothesis, the test methodology, and the result.
Plenty of people I work with would use a light bulb bullet for the hypothesis, a clipboard for the methodology, and a chart up or down for results.
It’s overly cute to me, but it works for them, and it does kind of provide a visual index.
Emoji should be always user configurable and opt-out add some —-fancy flag or some env variable if someone really wants them (you readme screenshot can let them know of they exists).
On a pedantic note (I know, as if anyone asked for more of that), hierarchy is not a single-dimension metric, it’s quite a bit more involved than just colour/internal visual complexity. A large part of it is positioning of an element relative to the viewport and other elements, negative space around it, etc. Unfortunately, in terminal output there is barely any control over that—unless you consider TUIs.
The placement in the visual hierarchy of emojis is their main feature. I think it's totally backwards to say that the visual hierarchy of terminal UIs must remain constrained to text with colors.
I'm sorry, but it's absolutely just as valid to indicate an error or other status with a bright emoji as with bright red text and exclamation points - as long as there is some support for greppability as well (when relevant).
Your point about multiplexers etc. apply to anything in the terminal, including bright red text.
> Your point about multiplexers etc. apply to anything in the terminal, including bright red text.
You did not read my comment. There is a concept of visual language. I specifically said that text colour (along with background colour, text style, etc.) constitutes the visual language of the terminal.
Bright red text follows general complexity pattern of text, with a distinguishing quality. Let’s call it standout factor x2, maybe x3 if you see in colour and red means danger. An inserted full colour image full of tiny details falls out of it completely, especially compared to Latin. The question of distinguishing qualities does not even make sense. It is text x10000.
Yes, red text in the next pane will also be slightly distracting, but it is nothing like a bunch of images sprinkled around my buffer.
If only there was a standards body that could perhaps spec how these work in terminals.
https://github.com/davidje13/tty-typesetter
I haven't used it in anger so can't vouch for it!
More background about how the smiley ended up in the IBM code page: https://www.vintagecomputing.com/index.php/archives/790/the-...
BTW, it is emitted with the sequence `Compose` `:` `)` (if you have Compose-key support installed+enabled)
They are also not limited to what some consortium and a couple of megacorporations think you should be able to express.
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.
GP explained already. Grapheme clusters ≠ glyphs. To find the number of glyphs you need the font.
An emoji can render as one or two or three or more glyphs depending on what font the user has installed, because many emoji are formed by joining two or more emoji by a ZWJ)
(Also even in a monospace font not all glyphs are of ﷽ equal width)
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 ...
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.
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.
(Prefix combining accents would also have made dead keys trivial rather than painful.)
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.
Issues (none): https://gitlab.com/gnachman/iterm2/-/issues/?sort=created_da...
Code: https://gitlab.com/search?project_id=252461&scope=blobs&sear...
Looks like it recognizes it but discards it. ):
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.
Indeed, but what's that got to do with my comment?
I've written a terminal emulator so very familiar how escape sequences are parsed. However your comment doesn't relate to my previous comment at all. At no point did I claim that unsupported codes wouldn't be ignored. What I said was Kitty's codes here are a pointless addition given we already have codes that more widely supported in terminal emulators and have been for several decades now.
> And DECHDL is not "standard" by any means
I assume you meant DECDHL not DECHDL ;) There's also DECDWL for double width too.
I never actually said they standardised.
What you've done here is conflate "standard" (typical/normal/de facto) with "standard" (ISO/ANSI/et al). It's a common way people misconstrue comments when they're looking for arguments rather than reading other people's comments charitably.
There's absolutely nothing wrong with the way I used the term "standard" -- it's pretty clear from the context that I wasn't claiming it is part of ECMA-48.
The reason I did use that term is because DECDHL and DECDWL are both supported on pretty much all DEC terminals (ie vt100 onwards) and xterm. They're a standard part of any hardware terminal or terminal emulator that seeks vt100 compatibility...which is most terminals arguably ostensibly anything created in the last 30 years in fact.
It would be more weird to advocate the use of some uncommon sequence created for one specific graphical terminal emulator that is a toddler in comparison. Yeah I get Kitty is popular, but it's hardly a de facto standard like vt100. Yet here we are -- people reinventing the wheel and thus making the already needlessly complicated problem of feature detection even harder still.
https://github.com/benjajaja/mdfried utilizes the new protocol and an image render fallback.
Also the tool you shared has nothing to do with this. It’s just a 3rd party utility.
Yeah. Right. Like that's going to happen.
The main author of Ghostty also wrote about how different terminals handle emojis https://mitchellh.com/writing/grapheme-clusters-in-terminals (2023)
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!
That got me wondering, are there any figlet fonts that support a lot of emoji? Certain non-ascii characters are already pretty well supported.
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.
And the follow up question: "What do emojis add to anything I'd read on the terminal?"
