10 ms·
Can your terminal do emojis? How big?
- phito 1y agoMy terminal doesn't even scale the text :(
- dima55 1y agoMine too. This is a feature :)
- yonatan8070 1y agoWhat's your terminal?
- phito 1y agoGuake and default gnome terminal
- b0a04gl 1y agoemoji 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 1y agoYeah, 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 1y 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 ... https://news.ycombinator.com/item?id=43851532 https://news.ycombinator.com/item?id=43851532
- PhilipRoman 1y agoAs fallback, you can also just emit the character and see how far the cursor advanced via CSI 6n (try printf '\x1b[6n')
- o11c 1y agoDoing 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.)
- duped 1y agoWhy 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 1y ago> This basically creates a software maintenance burden out of aether. So... basically all modern software?
- zarzavat 1y ago> Why do you need to sync with the shaping engine? 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)
- layer8 1y agoIt's not the font that is deciding how emoji sequences are rendered. The renderer may decide based on which characters exist in the available fonts, but it doesn't have to. Same for glyph width in terminals. It wasn’t uncommon for non-double-width-aware terminals to only draw half an emoji in a regular-width cell.
- zarzavat 1y agoHow else are you going to render a sequence such as Emoji ZWJ Emoji other than as two glyphs, if no composed glyph is defined in the user's font? That's how it's supposed to be rendered, for backwards compatibility.
- Joker_vD 1y agoThe 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 1y agoIt'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.
- deleted 1y ago[deleted]
- mmastrac 1y agoI'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.
- charcircuit 1y agoYou 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 1y agoWhat doesn’t justify shipping chromium these days?
- a5c11 1y agoSanity.
- dgl 1y agoThe 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/ 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://blink.sh
- notpushkin 1y agoHow does it compare to https://xtermjs.org/ https://xtermjs.org/?
- kergonath 1y agoYeah. Please don’t do that.
- liamkearney 1y agoThis is a really cool little interaction, thanks for sharing!
- LtWorf 1y agoThis is exposing so many bugs in konsole
- deleted 1y ago[deleted]
- yla92 1y agoI'd recommend folks to check-out https://ghostty.org 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 https://mitchellh.com/writing/grapheme-clusters-in-terminals (2023)
- the_mitsuhiko 1y agoWhich 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)
- moderation 1y agoRelevant GitHub Discussion [0] 0. https://github.com/ghostty-org/ghostty/discussions/3799 https://github.com/ghostty-org/ghostty/discussions/3799
- duped 1y agoIn 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.
- sureglymop 1y agoInteresting! Alternatively you could encode that in variation selectors on a zero width space: https://paulbutler.org/2025/smuggling-arbitrary-data-through-an-emoji/ https://paulbutler.org/2025/smuggling-arbitrary-data-through...
- account42 1y agoThis 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 1y agoCombining 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.
- duped 1y agoIt's already stateful
- kps 1y agoCombining characters and joiners should have been prefix rather than suffix/infix operators (and preferably in blocks by arity) so you'd always know without lookahead whether a grapheme cluster was complete. (Prefix combining accents would also have made dead keys trivial rather than painful.)
- nottorp 1y ago> At least provided they aren't overused, just like colour. Yeah. Right. Like that's going to happen.
- kps 1y agoToo many ‘modern’ UIs are designed by people who think the Las Vegas strip is the pinnacle of good taste.
- sebtron 1y agoAm 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.
- skerit 1y agoI'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 1y agoI’m not sure why you got downvoted for this. Is HN turning into reddit where downvote means “I have a different opinion”?
- bluebarbet 1y agoWithout activist moderation, that would appear to be the default outcome. Most humans seem to have an urge to stamp on dissonant opinions. Unfortunately.
- layer8 1y agoThis has always been the case: https://news.ycombinator.com/item?id=36674260 https://news.ycombinator.com/item?id=36674260 Please also see the very last guideline here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- LeoPanthera 1y agoYou are never the only one.
- account42 1y agoYou are the only one who doesn't understand that not all questions are meant literally though.
- panki27 1y agoWezTerm appears to support upscaling, but I only get the first emoji printed - the combining part does not work.
- p4cmanus3r 1y agoBack in my day... They didn't have emojis in terminals.
- uncircle 1y agoReally? So how did you understand each other, grandpa?
- DonHopkins 1y agoI heard they used to feel each others faces with their hands, like Hellen Keller, or with their mouths, like Mr. Peepers. https://www.youtube.com/watch?v=QV2kaJ5_8PU https://www.youtube.com/watch?v=QV2kaJ5_8PU
- voidUpdate 1y agoWhen was your day? Emoticons have been used in terminals since 1982
- account42 1y agoEmoticons 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 1y agoThey also lack semantics. There are downsides as well as up.
- account42 1y agoUsage rather than specifications determine semantics and due to the points in my previous post those often disagree for Unicode emojis.
- DonHopkins 1y agoThe 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://terminals-wiki.org/wiki/index.php/DEC_VK100 https://randoc.wordpress.com/2018/04/08/digital-equipment-dec-vk100-gigi/ 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!
- cyberge99 1y agoAs big as I want: imgcat empji.jpg
- hnlmorg 1y ago> 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.
- Joker_vD 1y agoIgnoring 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.
- hnlmorg 1y ago> 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. 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.
- deleted 1y ago[deleted]
- Aziell 1y agoThis 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.
- oneeyedpigeon 1y agoGreat. A feature that makes Apple's default Terminal better than iTerm or WezTerm. Just what I didn't need!
- nurumaik 1y agobtw I just checked and it is supported in wezterm
- oneeyedpigeon 1y agoI checked before I posted — the big font works for me, the mixed-emojis do not. Also, the big font is terribly pixellated in wezterm, both in terms of the emoji and the text. Maybe font configuration would help :shrug:
- vidarh 1y agoMost terminals that supports double-height/double-width seems to just scale the bitmap of the glyphs instead of properly rendering the font at twice the scale even if the font used is a vector font, for no particularly good reason.
- burnt-resistor 1y agoiTerm :1x sad face emoji: Issues (none): https://gitlab.com/gnachman/iterm2/-/issues/?sort=created_date&state=opened&search=DECDHL&first_page_size=20 https://gitlab.com/gnachman/iterm2/-/issues/?sort=created_da... Code: https://gitlab.com/search?project_id=252461&scope=blobs&search=DECDHL https://gitlab.com/search?project_id=252461&scope=blobs&sear... Looks like it recognizes it but discards it. ):
- aequitas 1y agoBut iTerm2 supports imgcat which lets you just dump full images into the terminal output.
- strogonoff 1y agoThe 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.
- skydhash 1y agoIt’s the same with colors in terminal. Some tools produces them even when piping it through another tool and then you have a mess of ansi codes on the output. 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).
- usrbinbash 1y agoThe 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?"
- naikrovek 1y agoCan 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.
- voodooEntity 1y agoAm i the only one reading the question and thinking "Please keep freaking emojis out of my shell" ?
- tiagod 1y agoProbably not. There were likely similar comments when colour was introduced.
- npteljes 1y agoKonsole 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.
- extraduder_ire 1y agoLarge 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.
- zzo38computer 1y agoIf 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.)