Live data from Hacker News

Terminal Support for Emoji

darrenburns.net

11–20 of 129 posts

Re: Terminal Support for Emoji

#11
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…

> or Unicode if your language needs that

Благодаря ти много, добър непознат.

Re: Terminal Support for Emoji

#13
post #2

It still pains me that Unicode decided to get in the business of curating an ever-growing clip art collection. It’s like the Oxford English Dictionary decided that they’re actually poets; their main job is suddenly to invent brand new words that let people write with an exciting level of density and poetic license; and those new dictionary words would also be multi-color because everybody owns a pack of colored penci…

Unicode needed to include written-on-paper glyphs that existed in the world. That makes sense to most people. But a lot, lot, lot of communication these days happen digitally (digital first). You can't scribble things as freely in a textbox like this one. You can certainly make suggestive combinations like `:)`, but you are pretty limited. (How do you scribble "family of three: mom, father, daughter" without any emoj…

> How do you scribble "family of three: mom, father, daughter" without any emojis?

How often do people need to do that; with that level of fidelity, right down to the composition of the family? My suspicion is not often. A short sentence does this description just as good and is much less ambiguous, as in written, concise communication that is "emoji-rich" is filled with so many details (such as the composition of the family and their skintone) it's often not clear which details are important for the message and which are not. In addition because emojis are rendered differently on different devices the meaning may be lost (e.g. when apple changed the gun emoji to a watergun, many messages took on different meanings depending on if a revolver was used or a watergun)

Re: Terminal Support for Emoji

#14
post #2

It still pains me that Unicode decided to get in the business of curating an ever-growing clip art collection. It’s like the Oxford English Dictionary decided that they’re actually poets; their main job is suddenly to invent brand new words that let people write with an exciting level of density and poetic license; and those new dictionary words would also be multi-color because everybody owns a pack of colored penci…

Unicode needed to include written-on-paper glyphs that existed in the world. That makes sense to most people. But a lot, lot, lot of communication these days happen digitally (digital first). You can't scribble things as freely in a textbox like this one. You can certainly make suggestive combinations like `:)`, but you are pretty limited. (How do you scribble "family of three: mom, father, daughter" without any emoj…

Are they glyphs or just vector graphics clip art?

Unicode doesn’t include ligature code points for every English word either. Somehow we manage to keep glyphs and words separate. Why couldn’t we do the same for inline graphics?

The copyright situation around emoji is actually worse now than if they’d been kept out of the standard. People expect emojis to look like on iPhone, but those specific graphics are owned by Apple, leaving everybody else scrambling for emojis that look close enough without infringing.

If emojis had originally been released as an open source library of SVG graphics together with some kind of standard shorthand way to refer to them without embedding an entire inline URL, we could have truly open clip art instead of this weird semi-proprietary mess.

Re: Terminal Support for Emoji

#15
IMO we should have left emojis out of everything that is rendered by convention with monospaced fonts. But of course I respect the desire for displaying rainbow farting unicorns even in consoles, so let's find a solution for this.

Re: Terminal Support for Emoji

#16
Honestly, seems like the problem with wcwidth's implementations. Most of them have been reporting almost all emojis as having width 1 (and some very non-invisible symbols as having with 0) for years, to this very day, for some unexplained reason despite regular web rants of how this is wrong. Check out this one: [0]. It's 8 years old! The problems are still there.

[0] https://eev.ee/blog/2015/09/12/dark-corners-of-unicode/#comb...

Re: Terminal Support for Emoji

#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. Obviously I haven't tested all terminal emulators in existence, though :-)

I patched a similar bug in screen earlier this year (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039503), which indicates the kind of stuff you have to go through.

Re: Terminal Support for Emoji

#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.

Re: Terminal Support for Emoji

#20
post #7

works fine with Windows Terminal: http://0x0.st/H_S1.png but yes to be fair, the width on those ridiculous 5 codepoint emoji is off.

Kitty on macOS also works fine with all cases, including the correct width.

Kitty has the wrong width: https://github.com/kovidgoyal/kitty/issues/3810

It doesn't immediately overwrite the emoji with the next character, but the cursor position is off, which leads to wrapping problems down the line.

Post reply on HN