Live data from Hacker News

Terminal Support for Emoji

darrenburns.net

101–110 of 129 posts

Re: Terminal Support for Emoji

#101
post #38
post #32

Earlier quoted context omitted.

> A short sentence does this description just as good and is much less ambiguous so you're now dictating what can be said, rather than designing a system for which _anything_ that could be said is possible? You're missing the goal of a system of writing and representation.

The system exists. It's text.

how would you write something that's not ascii character based, such as hieroglyphs?

Re: Terminal Support for Emoji

#102
post #19
post #3

Interestingly, Microsoft Terminal renders all of these correctly!

Microsoft Terminal is actually pretty good. I was surprised when I configured git bash as my main shell there and when opening it via right-click in Explorer, it correctly translated the path and opened the shell in the correct folder.

Is this the same terminal that Casey Muratori was complaining about how there's basic performance issues? (see https://news.ycombinator.com/item?id=28743687)

Re: Terminal Support for Emoji

#103

Are there some well defined Unicode subsets, e.g. one without Emoji? (I'm only vaguely aware of XML specifying "Unicode without control characters" in the beginning).

Basic Multilingual Plane should be it.

While most emoji are outside the BMP, not all are. E.g., {U+2622, U+FE0F} (radiation symbol + variation selector) or even just U+2728 (sparkles). See https://unicode.org/reports/tr51/#Presentation_Style

Re: Terminal Support for Emoji

#104
post #80
post #74

I'm on the VS Code team and maintain xterm.js which is what Hyper's frontend is based on. There are actually multiple developments happening in this area. First, there's a contribution from the author of DomTerm which adds grapheme cluster support to xterm.js, which will correctly merge and size things like emoji that are called out in the post. This is currently based on Unicode 15. See https://github.com/xtermjs/xt…

I spent a lot of time on this topic (see https://news.ycombinator.com/item?id=37048434 ). Feel free to get in touch and discuss. I'm happy to help.

I'm the author of DomTerm and the above-mentioned xterm.js PR. Both use the full UnicodeGrapheme Cluster Boundaries algorithm (https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundarie...). However, I haven't seen any specifications for how wide the resulting clusters should be in a mono-space context. So unless we enhance terminals to handle variable-width fonts (which I've been thinking about), we need to took at other terminals and make judgement calls. Generally, the width of a cluster is the width of the widest codepoint. Also, I decided that a "normal" character followed by emoji-presentation makes it 2 columns wide.

In your linked-to article, you suggest 2-em dash and 3-em dash should be 3 and 4 columns respectively. That might be reasonable, but it is explicitly contrary to the EastAsianWidths specification. You also suggest that Pictographics fullowed by text-presentation should have width 1. That seems reasonable, though I don't implement that.

Re: Terminal Support for Emoji

#105

Are there some well defined Unicode subsets, e.g. one without Emoji? (I'm only vaguely aware of XML specifying "Unicode without control characters" in the beginning).

Basic Multilingual Plane should be it.

Unicode Character 'HOURGLASS' ⌛ (U+231B) says hello.

Re: Terminal Support for Emoji

#106
post #101
post #38

Earlier quoted context omitted.

The system exists. It's text.

how would you write something that's not ascii character based, such as hieroglyphs?

A set of hieroglyphs for a formally designed and recognized language that is in use to communicate is one thing. Endless bits of arbitrary clip art is another.

Re: Terminal Support for Emoji

#107
post #6

I never have understood the push to emojify everything. But commit messages, options in menus, status outputs, you name it: I think we'd be better off leaving it in plain ASCII (or Unicode if your language needs that, just as long as you don't dip into the emoji). Emoji are quite nice for messaging people and occasionally some of the more generic ones can be useful for status indicators (think the red and green circl…

Emojis are God's way of getting english-speaking developers to test characters outside the ASCII range.

[dead]

Re: Terminal Support for Emoji

#108
post #18

I don't know of a single terminal that actually gets these ZWJ emoji sequences right. There are several terminals who will render them, but I haven't seen any actually get the width calculations correct. (E.g., https://github.com/kovidgoyal/kitty/issues/3810 .) Part of the problem is that it really messes up the idea of a rectangular grid of base characters in memory, so you'll need some sort of indirection. Obviousl…

DomTerm gets the linked test right.

Re: Terminal Support for Emoji

#109

Are there some well defined Unicode subsets, e.g. one without Emoji? (I'm only vaguely aware of XML specifying "Unicode without control characters" in the beginning).

Yes. ASCII is one. Latin-1 is another.

Depending on what degenerate system you are in, U+00A9 © COPYRIGHT SIGN might render like a emoji, so ISO/IEC 8859-1 isn't safe.
Post reply on HN