Live data from Hacker News

Terminal Support for Emoji

darrenburns.net

61–70 of 129 posts

Re: Terminal Support for Emoji

#61

Earlier quoted context omitted.

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? Using nifty little things called jpegs.

How do you propose they get transmitted? In-band in the middle of text (good luck reading that with an unsupported editor), or through servers, necessitating NAT and all that good fun?

Since the images can be arbitrary you also open yourself up to bugs in the parser.

All around a much, much worse idea compared to text emojis.

Re: Terminal Support for Emoji

#62

Earlier quoted context omitted.

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? Using nifty little things called jpegs.

How is that any better? You can’t integrate them easily in the text, you still have to store the images and send them around, and there’s no way of normalising them, which means that this has all the inconvenience of Unicode without any of the features that help handling code points and glyphs, and even smaller probability of it being rendered correctly.

Re: Terminal Support for Emoji

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

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

Why such a distinction? Symbols are very useful in commit messages because they can convey a message at a glance that would otherwise require parsing the message. A big, visible symbol for bug fixes and another one for new features makes a lot of sense. Once we’re there, how is it better to use things like Chinese characters rather than emojis?

Making emojis work everywhere also has the very useful side effect that the rest of Unicode works as well. Which is kind of important for the vast majority of the people on earth who need more than ASCII to write in their mother tongue. On balance, it is better that they are supported properly even if you personally dislike them.

Not even considering the moral aspects of wanting to impose on other a way of communicating.

Re: Terminal Support for Emoji

#64
post #56
post #22

Earlier quoted context omitted.

> How do you propose that Unicode include glyph innovations that are digital-first? Why does Unicode specifically need to include novel "innovations"? It's arguably failure of the community that we have not been able to standardize interoperable higher level rich text formats, so now everything and kitchen sink needs to be bolted on Unicode instead in the name of interop.

> Why does Unicode specifically need to include novel "innovations"? Unicode chose to get into emoji because Japanese carriers were already making their own private character sets with emoji, and Unicode has a goal of being a superset of all other (relevant) character sets. (Arguably emoji support in Unicode has been a resounding success. Look at the world-wide enthusiasm around each new Unicode version that gets ann…

It also brought broken handling of code points beyond the BMP to the forefront and dealing with Unicode text is correct in much more places by now. Previously the only people who noticed were those who needed obscure Han ideagraphs, hieroglyphs, and other things that are not terribly useful or interesting to the vast majority of people.

Re: Terminal Support for Emoji

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

I quite like them in GitHub release descriptions, e.g. those by Ghost CMS https://github.com/TryGhost/Ghost/releases/tag/v5.52.0

Re: Terminal Support for Emoji

#66
post #58
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…

I found wide character support to be surprisingly good across the terminal emulators I tried on macOS and Linux. This testing was done earlier this year when I was building support for Unicode variable names into my $SHELL (more to support foreign languages than glyphs but the end result is the same) It’s worth noting that wider character support needs to be implemented in both the terminal emulator AND and the conso…

So which ones support the ZWJ sequences correctly and fully?

Re: Terminal Support for Emoji

#67
post #21
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 is only curating the clip-art collection, inventing brand-new entries is left to interested third parties. So a closer analogy would be the Oxford English Dictionary adding newly-coined words, which—of course—they do https://www.oed.com/discover/the-oed-september-2021-update/ in addition to expanding coverage of older words (analogous to the Unicode Consortium working on historical scripts). NB if you don't l…

The analogy is that Oxford Dictionary is adding words, BUT ... you can only use those words and your words will be automatically replaced by synonyms on different platforms.

Re: Terminal Support for Emoji

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

> Unicode needed to include written-on-paper glyphs that existed in the world.

If it was the case, Emoji is seriously lacking a penis. I mean, seriously, give men a way to draw and this is what you will get. There are already existing "subjective combinations" like 8===D and the eggplant emoji for which it is its most common use. There is a proper penis in the hieroglyphics, but just because there is a hieroglyphic doesn't mean there is no corresponding emoji (ex: eye).

On the other hand, many emoji pass even though I have never seen anything remotely similar being scribbled ever, it is the addition to the emoji block that drove its use. Plus, because inclusivity, all its equivalents in different genders, skin tones, cultures, etc...

Clearly, Unicode acts as an arbiter here. It decides on what it thinks it is "good" rather than what is really in use. And it is not just about penises, the hangman is also absent, as is the "gun pointed on head" sign (suggesting suicide) that is commonly used in real life.

Worth noting that the first emoji were included because they were already in common use before Unicode, in Japanese phones specifically. Unicode just included them so that Japanese users could switch to Unicode without loss of functionality.

Re: Terminal Support for Emoji

#69
post #27

Earlier quoted context omitted.

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 You don't. You use text.

I still was trying to figure out how an emoji represents a family.

Re: Terminal Support for Emoji

#70
post #65
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…

I quite like them in GitHub release descriptions, e.g. those by Ghost CMS https://github.com/TryGhost/Ghost/releases/tag/v5.52.0

I find these a visual noise. What can be achieved with a subheading "Bug fixes", "Features" etc. is repeated in all lines.
Post reply on HN