[HN Gopher] Can your terminal do emojis? How big?
___________________________________________________________________
Can your terminal do emojis? How big?
Author : dgl
Score : 171 points
Date : 2025-06-24 02:13 UTC (20 hours ago)
(HTM) web link (dgl.cx)
(TXT) w3m dump (dgl.cx)
| b0a04gl wrote:
| 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 wrote:
| 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 e and even Arabic characters, just fine.
| o11c wrote:
| `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
| PhilipRoman wrote:
| As fallback, you can also just emit the character and see
| how far the cursor advanced via CSI 6n (try printf
| '\x1b[6n')
| o11c wrote:
| 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.)
| duped wrote:
| 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 wrote:
| > _This basically creates a software maintenance burden out
| of aether._
|
| So... basically all modern software?
| zarzavat wrote:
| > 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 wrote:
| It'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 wrote:
| How 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.
| kccqzy wrote:
| > It wasn't uncommon for non-double-width-aware terminals
| to only draw half an emoji in a regular-width cell.
|
| And you are just describing bugs. This is not just an
| emoji issue: it will also fail to render CJK characters.
| Joker_vD wrote:
| > An emoji can render as one or two or three or more glyphs
| depending on what font the user has installed,
|
| And how the program that prints such emojis should deal
| with this? Like, how should e.g. readline handle the user
| pressing the Backspace key after inputting such an emoji
| after prompted for input? It needs to know precisely how
| many lines and columns user's input takes: a _huge_ chunk
| of code in that library is devoted precisely to this,
| because simply emitting "\b \b" doesn't work.
|
| And if the user opens the terminal emulator's settings and
| changes the font, should the program be sent some signal to
| redraw the window, as it happens when the window size
| changes? E.g. that emoji was in a 10-columns wide edit
| field and so characters after it fit when that emoji was 1
| column wide, but now it's 2 columns wide, so the ncurses
| should now trim the last character in that field.
|
| Or try this funny little experiment, for instance: resize
| your terminal to something like 30 cols by 5 rows and run
| "script -c bash temrinal_log.txt". Now hold "a" key until
| you enter enough "a"s that the shell prompt is no longer
| visible. Now hold Backspace until you've erased all "a" and
| cursor no longer moves. What do you see on the screen? Now
| press Ctrl-D to exit the "script" session, and study the
| transcript in temrinal_log.txt in a hex editor. Ponder on
| the mechanisms that bash (readline inside it, really) uses
| to implement line-editing.
| mminer237 wrote:
| Some monospace fonts do fit [?] into one normal-sized
| character by squeezing it into three mini lines.
| Joker_vD wrote:
| 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 wrote:
| 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.
| mmastrac wrote:
| 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.
| charcircuit wrote:
| 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 wrote:
| What doesn't justify shipping chromium these days?
| dgl wrote:
| 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)
|
| [2]: https://blink.sh
| notpushkin wrote:
| How does it compare to https://xtermjs.org/?
| a5c11 wrote:
| Sanity.
| kergonath wrote:
| Yeah. Please don't do that.
| utf_8x wrote:
| Oh god, please don't give them ideas
| noisy_boy wrote:
| 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.
| layer8 wrote:
| It was traditionally often single-width in text
| representation, but double-width in emoji presentation: https
| ://en.wikipedia.org/wiki/Emoji#Emoji_versus_text_presen...
| kps wrote:
| And Unicode threw out all pretense of stability by
| retroactively changing some characters to default-emoji.
| a5c11 wrote:
| 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 wrote:
| 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.
| kergonath wrote:
| 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 wrote:
| > 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.
| tetha wrote:
| 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.
| kergonath wrote:
| > 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.
| thaumasiotes wrote:
| > True, but my prompt is full of colour ASCII characters
| so emoji stand out.
|
| Huh? How often does your prompt appear inside the output
| you're reading?
| kergonath wrote:
| Every time I grep something. True, it's not a major
| issue, but we are talking about preferences here.
| kps wrote:
| And then I have to guess _which_ unicode cross this
| particular tool picked so I can search for it in log.
| kergonath wrote:
| Emojis are for me. The grep-able stuff comes afterwards,
| in ASCII.
| twic wrote:
| Until then, as it happens, an old colleague of mine is working
| on a JS library to paper over the cracks:
|
| https://github.com/davidje13/tty-typesetter
|
| I haven't used it in anger so can't vouch for it!
| liamkearney wrote:
| This is a really cool little interaction, thanks for sharing!
| phito wrote:
| My terminal doesn't even scale the text :(
| dima55 wrote:
| Mine too. This is a feature :)
| yonatan8070 wrote:
| What's your terminal?
| phito wrote:
| Guake and default gnome terminal
| LtWorf wrote:
| This is exposing so many bugs in konsole
| npteljes wrote:
| Which bugs?
| LtWorf wrote:
| rendering of large emojis... That works but they reappear
| after clearing or half of it randomly disappears.
| yla92 wrote:
| 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)
| the_mitsuhiko wrote:
| 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)
| moderation wrote:
| Relevant GitHub Discussion [0]
|
| 0. https://github.com/ghostty-org/ghostty/discussions/3799
| duped wrote:
| 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.
| sureglymop wrote:
| Interesting! Alternatively you could encode that in variation
| selectors on a zero width space:
| https://paulbutler.org/2025/smuggling-arbitrary-data-through...
| account42 wrote:
| 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 wrote:
| 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.
| duped wrote:
| It's already stateful
| kps wrote:
| Combining 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 wrote:
| > At least provided they aren't overused, just like colour.
|
| Yeah. Right. Like that's going to happen.
| kps wrote:
| Too many 'modern' UIs are designed by people who think the Las
| Vegas strip is the pinnacle of good taste.
| brookst wrote:
| Kids these days!
| kps wrote:
| Yes, for many people astigmatic halation gets worse over
| time.
| nottorp wrote:
| ... I'd take a Las Vegas strip UI if it had contrast and it
| were easy to read ...
| sebtron wrote:
| 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.
| LeoPanthera wrote:
| You are never the only one.
| account42 wrote:
| You are the only one who doesn't understand that not all
| questions are meant literally though.
| layer8 wrote:
| I don't think he's the only one.
| Springtime wrote:
| 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 wrote:
| I really hate that Unicode retroactively made some pre-
| existing smileys into colored-by-default emojis.
| magackame wrote:
| Noto Emoji has all emoji as monochrome outlines.
| kergonath wrote:
| > 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.
| adastra22 wrote:
| It was cute before it was everywhere thanks to LLMs.
| uncircle wrote:
| It was already annoying before LLMs got popular. Now it's
| gotten out of hand <rocket emoji>
|
| Emojis in repos and CLI tools is the textual counterpart to
| the soulless Alegria art style:
| https://en.m.wikipedia.org/wiki/Corporate_Memphis
| DonHopkins wrote:
| I dislike putting ASCII characters in CLI tools and logs and
| think they should be PURE EMOJI! [ wink emoji ;) ]
| pknerd wrote:
| > Am I the only one who actually dislikes the recent trend of
| putting emojis everywhere in CLI tools?
|
| No.
| skerit wrote:
| 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 wrote:
| I'm not sure why you got downvoted for this. Is HN turning
| into reddit where downvote means "I have a different
| opinion"?
| bluebarbet wrote:
| Without activist moderation, that would appear to be the
| default outcome. Most humans seem to have an urge to stamp
| on dissonant opinions. Unfortunately.
| layer8 wrote:
| This has always been the case:
| https://news.ycombinator.com/item?id=36674260
|
| Please also see the very last guideline here:
| https://news.ycombinator.com/newsguidelines.html
| hnlmorg wrote:
| 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).
| bigstrat2003 wrote:
| 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 wrote:
| 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.
| ffaser5gxlsll wrote:
| It's dumb because a font a allowed to re-interpret the
| actual image, but in doing so you also frequently change
| the meaning of the symbol. This is not a problem for text,
| but for images just changing the color of the fill might
| completely change the meaning of the sentence.
|
| See the old apple gun vs squirt gun. The same is true also
| when using stuff like whatsapp on android, where the os
| keyboard shows you one image from the system theme, but the
| one which you see inserted in the text is _not_ what you
| selected, but at least is partially better than sending
| something without knowing how it will be rendered, which is
| what most chat messages have realized after trying to
| simply using the system font.
|
| So at that point, you have to switch to a different custom
| font just for the emoji block, and you're still limited to
| what unicode allows instead of just bundling whatever image
| you want (which is a great excuse to sell new phones with
| "new emojis" I guess).
| thaumasiotes wrote:
| > and you're still limited to what unicode allows instead
| of just bundling whatever image you want (which is a
| great excuse to sell new phones with "new emojis" I
| guess).
|
| Except that every chat client now supports stickers,
| which are nothing but custom images that are guaranteed
| to render the same way for the recipient that they do for
| you. The recipient does _not_ need to have them
| installed.
|
| But stickers have to be their own full message in the
| clients I know of. Once they start to be integrated into
| textual messages, clients will have developed all the way
| to where MSN messenger was in 2003.
| layer8 wrote:
| No, the argument was that existing character sets used in
| Japanese feature phones had them. Because Japanese
| characters are wider than Western characters, those
| platforms could be more creative with pictographic
| characters as well, and could easily add color due to the
| proprietary phone OS. Unicode added them because Unicode's
| goal is to provide round-trip compatability with existing
| character sets.
|
| https://blog.emojipedia.org/correcting-the-record-on-the-
| fir...
| juliangmp wrote:
| 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.
| nickdothutton wrote:
| 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.
| lgeorget wrote:
| 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.
| lifthrasiir wrote:
| 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.
| graemep wrote:
| 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.
| ffaser5gxlsll wrote:
| I dislike emojis in general when combined with running text.
| Especially in terminals or character-based interfaces with
| fixed-width fonts.
|
| 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.
| panki27 wrote:
| WezTerm appears to support upscaling, but I only get the first
| emoji printed - the combining part does not work.
| p4cmanus3r wrote:
| Back in my day... They didn't have emojis in terminals.
| uncircle wrote:
| Really? So how did you understand each other, grandpa?
| DonHopkins wrote:
| I 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
| voidUpdate wrote:
| When was your day? Emoticons have been used in terminals since
| 1982
| account42 wrote:
| 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 wrote:
| They also lack semantics. There are downsides as well as
| up.
| account42 wrote:
| Usage rather than specifications determine semantics and
| due to the points in my previous post those often
| disagree for Unicode emojis.
| oneeyedpigeon wrote:
| I'm glad you recognise the value of usage when it comes
| to emoticons vs. emoji...
| arccy wrote:
| emoji lack clear semantics too, consider the eggplant.
| oneeyedpigeon wrote:
| I think there's a difference. The code point will always
| mean "eggplant", it just happens that the concept can be
| interpreted in different ways according to context--just
| like the word itself. But ":-)" can only ever mean "colon
| minus rparens" before further interpretation.
| skydhash wrote:
| What's it called is syntax, what it's means is always
| context dependent. That's why we invented formal
| notation, so that we can have context free interpretation
| (it's bundled with its semantic so you don't need to
| apply some context to it)
| account42 wrote:
| Actually, according to Unicode, "-" doesn't mean minus -
| U+002D is hyphen-minus.
|
| And as for the eggplant, your semantics-as-specified are
| useless when 99.9% of the usage has a different intended
| meaning due to the inherent lack of expressiveness in a
| corporate-approved emoji language.
| layer8 wrote:
| Emojis also severely lack semantics. They are specified
| in terms of what they should visually depict, not what
| they are supposed to mean.
| thaumasiotes wrote:
| > or for absolute maniacs: (:
|
| To be fair, Unicode allows for that variant too:
| https://emojipedia.org/upside-down-face
| jiggawatts wrote:
| Agreed, but Unicode allows me to express the emotion that I
| most commonly feel when working in the IT industry:
| disapproval. tth_tth
| gylterud wrote:
| U+263A entered Unicode in 1993, afaik. Plan9 had utf8 support
| in the terminal back then!
| Findecanor wrote:
| 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)
| layer8 wrote:
| This character was code 0x01 in the original IBM PC code page
| (https://en.wikipedia.org/wiki/Code_page_437), and hence in
| DOS. It was displayed single-width and monochrome just like
| any other 8-bit character, never causing any rendering
| issues, unlike emojis today. It was added to Unicode for
| round-trip compatibility with that code page.
|
| More background about how the smiley ended up in the IBM code
| page: https://www.vintagecomputing.com/index.php/archives/790
| /the-...
| MisterTea wrote:
| UTF-8 was developed by Rob Pike and Ken Thompson on a napkin
| in a diner and implemented in Pikes Plan 9 making it the
| first UTF-8 OS.
| SSLy wrote:
| you'll need same complexity, sans multi-coloured glyphs, for
| any non-latin script anyway.
| DonHopkins wrote:
| 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!
| cyberge99 wrote:
| As big as I want: imgcat empji.jpg
| hnlmorg wrote:
| > 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 wrote:
| 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.
| hnlmorg wrote:
| > 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.
| zzo38computer wrote:
| Both kind of "standard" are worth to look at; often
| existing codes would be suitable. However, there are
| sometimes some things that there does not seem to be a code
| for.
| hnlmorg wrote:
| I'm an advocate for creating codes to solve problems.
| I've literally written a terminal emulator with that in
| mind: https://github.com/lmorg/ttyphoon -- there I
| defined codes for graphical features like interactive
| tables and inlining AI elements in non-intrusive ways.
|
| My qualm isn't with defining new escape sequences. It's:
|
| 1. calling Kitty's specific double height/width escape
| sequences "modern" when it's using the same 1970s
| principles as the original double height/width codes.
|
| 2. Kitty reinventing the wheel here when it adds no
| benefit to the original codes.
|
| It's the same reason I get annoyed that there are 4+
| different proprietary codes for inlining images.
|
| All of this continual reinvention of the same ideas just
| creates more problems than it solves.
| the_gipsy wrote:
| It does improve because IIRC support for the old sequence
| cannot be reliably detected.
|
| https://github.com/benjajaja/mdfried utilizes the new protocol
| and an image render fallback.
| hnlmorg wrote:
| I don't buy that argument. The old sequence is part of vt100
| and supported by xterm. The new sequence is only supported by
| Kitty. If the Kitty dev wanted to make feature detection
| easier then they wouldn't have duplicated a feature that has
| been a staple for terminals for literally decades.
|
| Also the tool you shared has nothing to do with this. It's
| just a 3rd party utility.
| Aziell wrote:
| 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.
| oneeyedpigeon wrote:
| Great. A feature that makes Apple's default Terminal better than
| iTerm or WezTerm. Just what I didn't need!
| nurumaik wrote:
| btw I just checked and it is supported in wezterm
| oneeyedpigeon wrote:
| I 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 wrote:
| Most 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 wrote:
| iTerm :1x sad face emoji:
|
| 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. ):
| aequitas wrote:
| But iTerm2 supports imgcat which lets you just dump full images
| into the terminal output.
| strogonoff wrote:
| 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.
| skydhash wrote:
| It'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).
| calvinmorrison wrote:
| If you have a tool users are pipe data into you should be
| able to handle terminal escape sequences. My two cents.
| wavemode wrote:
| Not feasible. What happens if the actual data you're trying
| to process happens to contain a sequence of bytes which
| could be interpreted as an escape sequence? Now you've
| ruined the user's data by modifying it.
| calvinmorrison wrote:
| some allowances must be made for text co-mingling in the
| UI or we just all need to move to structured crap like
| PowerShell.
|
| nobody seems to complain about other control characters
| like line feeds....
|
| but yeah you can also check for $TERM or try to guess
| other ways.
| strogonoff wrote:
| I agree that configurability helps, and flags to make output
| more/less plain exist. Just wanted to present a viewpoint
| based on a concept I learned studying visual design.
| Colourful text and emoji are on totally different levels when
| it comes to attention grabbing!
| simonask wrote:
| Strong "get off my lawn" vibe here.
|
| 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.
| strogonoff wrote:
| You are free to disagree.
|
| > 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.
| aendruk wrote:
| Sounds like a reasonable compromise might be to set a
| monochrome emoji font in the terminal. I think you've convinced
| me to try it.
| Gud wrote:
| Or you know, :-)
| aendruk wrote:
| And how do you achieve that, transform the output of every
| command? Or just patiently play the long game of
| petitioning on internet forums?
| Gud wrote:
| I'm a patient man.
| layer8 wrote:
| But you still want the warning emoji to be yellow, so you
| also have to add ANSI sequences around it.
| strogonoff wrote:
| I think lower-detail emoji versions (monochrome or with
| sparse use of colour) could definitely work better! Massive
| amount of work though, creating such a version for every
| possible emoji...
| amelius wrote:
| Ok, noted. Unicode needs an escape code to specify the level of
| the visual hierarchy.
| colejohnson66 wrote:
| Just add a few more ZWJ-based sequences to the ever growing
| list
| WorldMaker wrote:
| They sort of already exist, many emoji are turned "on"
| (colorful presentation or Emoji Presentation) with
| Variation Selector 16 [0] and many can be forced "off"
| (monochrome presentation) with Variation Selector 15 [1].
|
| (Not all fonts handle all variations, though, in both
| directions.)
|
| [0] https://codepoints.net/U+FE0F [1]
| https://codepoints.net/U+FE0E
| jerf wrote:
| This post nicely doubles as an explanation of why current-gen
| LLM's tendencies to spray emoji everywhere is annoying.
| Replacing bullet points with rocket ships and hand symbols
| pointing at things and spraying the emoji everywhere, rather
| than highlighting the things the emoji are trying to decorate,
| actually tends to _obscure_ the thing being nominally
| highlighted under the massively over-powerful colorful symbols
| entirely. The initial visual impression of these texts is "a
| splattering of colorful symbols, with some incidental boring
| text around them" and it takes time and cognitive effort to
| filter out the blaring color, which has no useful content in
| it, and get to the real content.
| brookst wrote:
| I think this is more about age cohorts than anything
| intrinsic to emojis.
|
| 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.
| jerf wrote:
| I specifically referenced LLM use because it seems to
| rather pointlessly just spray them everywhere. I didn't
| complain about them existing in general. I can old-fogey
| quibble with specific uses when humans add them with
| purpose but can also easily acknowledge it's just a taste
| matter. But LLMs seem to love that rocket ship, the green
| checkmark, that celebration emoji with the confetti coming
| out of the cardboard tube, and a few other ones that are
| only loosely related to the content. Also loves to point
| fingers at links, which are often already distinguished in
| the text. And seeing through all that is a real pain.
|
| That your eyes are drawn more to color and shape than
| monochrome text is not an old person thing. That's a human
| thing.
|
| In many cases this becomes an arms race too, where people
| start competing to make their content more colorful than
| the last, and that arms race has only one end, where the
| "engagement hooks" completely overwhelm the content. We've
| seen that one play out in a number of places already.
| whateveracct wrote:
| That just happens because those LLMs were trained in medium
| blog posts haha
| jerf wrote:
| I really should have included the word "default" in there
| somewhere. It's effectively impossible to make any blanket
| statement about "what LLMs do" because it's one prompt away
| from doing almost literally anything else.
|
| However, it's a style that currently has a lot of
| popularity.
|
| Indeed, asking for answers in the style of Alice in
| Wonderland is one of my favorite things to do, like
| programming questions. The extra frisson from something so
| non-whimsical being expressed so whimsically via such a
| complicated technology goes all the way around the
| "cringe/cool" circle at least twice; you can decide for
| yourself where it lands in the end.
|
| I did finally hear about the students getting wise to LLM
| style issue. I just saw a YouTube video about a student
| saying he would 1. have the LLM write his essay 2. rephrase
| the first two paragraphs in his own style 3. tell the LLM
| to rewrite the essay from step 1 in the style exemplified
| from his rewrite. AI detection tools, which are really
| "default AI detection tools", call it 0% AI. Stick a fork
| in them, they're done at that point. I don't think any "AI
| detection tool" is likely to defeat that, unless LLMs
| suddenly freeze in advancement for, oh, at least 3 years or
| so, which seems unlikely.
| bjourne wrote:
| I have emojis in my prompt to convey the status of the git
| branch I'm working on. It's much more space-efficient than
| using English strings.
| codedokode wrote:
| I noticed this a lot - when emojis stand out and distract from
| the text. They should be smaller and use less saturated colors.
| usrbinbash wrote:
| 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?"
| naikrovek wrote:
| 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.
| voodooEntity wrote:
| Am i the only one reading the question and thinking "Please keep
| freaking emojis out of my shell" ?
| tiagod wrote:
| Probably not. There were likely similar comments when colour
| was introduced.
| npteljes wrote:
| 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.
| extraduder_ire wrote:
| 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.
| zzo38computer wrote:
| 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.)
___________________________________________________________________
(page generated 2025-06-24 23:01 UTC)