Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Terminal Support for Emoji

darrenburns.net

Post reply on HN
Print view View original

121–129 of 129 posts

Re: Terminal Support for Emoji

#121

Post by Closi »

zamadatix wrote: post #112
Closi wrote: post #48

Earlier quoted context omitted.

The tahitans can deal with communication just fine with only 13 letters, so I guess we could probably trim the letters b, c, d and g out of unicode too. With enough optimisation we might just be able to communicate with just a boolean-based language. (i.e. why limit written communication rather than make it richer)

That you can take something too far in one direction doesn't give reason or explanation for anything except "don't take it too far in that direction". There are probably good explanations why not to take things infinitely far in either direction but they don't really help explain where the line should be drawn. I think the actual argument here is encoding of seemingly arbitrary colored pictorial combinations overcomp…

That’s true, but if your argument can be extended to absurdity it probably can't be used to justify where the 'correct' place on the scale is to land.

Re: Terminal Support for Emoji

#122

Post by dr_zoidberg »

sphars wrote: post #43
dr_zoidberg wrote: post #40

Earlier quoted context omitted.

Is that Windows Terminal, or have they renamed it yet again?

Yeah, just Windows Terminal: https://github.com/microsoft/terminal/

I thought I might have missed a rename. Microsoft tends to rename things at random times.

Re: Terminal Support for Emoji

#123

Post by GuB-42 »

noAnswer wrote: post #97
cnity wrote: post #75

Earlier quoted context omitted.

Unicode actually does include a penis: 𓂸 There is even a "phallus with emission" variant.

Interesting: U+130BA EGYPTIAN HIEROGLYPH D053 (phallus with liquid issuing from it) 𓂺 Not even BabelMap or BabelPad have a font showing more than a square.

I just discovered that the default Windows 10 font censors phalluses except when they are next to another hieroglyph.

𓂲𓂺

Re: Terminal Support for Emoji

#124

Post by TeMPOraL »

JellyYelly wrote: post #13
avgcorrection wrote: post #8

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? 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 th…

> How often do people need to do that;

Surprisingly, this happens. I recently started to use a lot of emojis, including ones like these, to name calendar events - because I use a watch face on my smartwatch that renders the next 12 hours worth of events on the clock face, and given the small space, many of the events can fit three or four letters of description. Emojis work as great workaround, because I can encode things like "takeoff, gate A11" in 4 visual characters, or "doctor's visit" in one.

(I prefix the event titles with emojis rather than replace the longer form completely, because some of those events are shared, and sometimes I forget what an emoji stands for anyway...)

Now, this is perhaps an unique use case, but I found myself doing this in other scenarios too, like task planners - the common thread is, "not enough space to fit full label".

Re: Terminal Support for Emoji

#125

Post by worthless-trash »

aendruk wrote: post #71
ungamedplayer wrote: post #69

Earlier quoted context omitted.

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

With the scheme demonstrated at the beginning of the article. 1F468 man 200D zero width joiner 1F469 woman 200D zero width joiner 1F467 girl

Thats just three people close together, could be a Torball team.

Re: Terminal Support for Emoji

#126

Post by hnlmorg »

Sesse__ wrote: post #66
hnlmorg wrote: post #58

Earlier quoted context omitted.

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?

I cannot claim to have tested every ZWJ character on every terminal emulator but if you find any ZWJ related bugs in murex shell https://GitHub.com/lmorg/murex then it will be treated as a serious bug because Murex does have international users so aims for greater compatibility with other language writing systems (albeit the documentation is presently only available in English).

Re: Terminal Support for Emoji

#127

Post by avgcorrection »

zamadatix wrote: post #112
Closi wrote: post #48

Earlier quoted context omitted.

The tahitans can deal with communication just fine with only 13 letters, so I guess we could probably trim the letters b, c, d and g out of unicode too. With enough optimisation we might just be able to communicate with just a boolean-based language. (i.e. why limit written communication rather than make it richer)

That you can take something too far in one direction doesn't give reason or explanation for anything except "don't take it too far in that direction". There are probably good explanations why not to take things infinitely far in either direction but they don't really help explain where the line should be drawn. I think the actual argument here is encoding of seemingly arbitrary colored pictorial combinations overcomp…

> That you can take something too far in one direction doesn't give reason or explanation for anything except "don't take it too far in that direction".

Why or how does the Tahitian language take things too far?

Re: Terminal Support for Emoji

#128

Post by tym0 »

jlokier wrote: post #114
foepys wrote: post #19

Earlier quoted context omitted.

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.

I didn't like Windows Terminal when I used it over the last few months at the last $job because my choices of software were limited and it was better than the Windows Console. There seems to be no way to make the cursor clear and visible on all background colours that I used for CLI and text editing. I ended up having to use a difficult-to-see 50% grey cursor, as a compromise that was better than losing the cursor co…

Hmmm, interesting I use ctrl-space as my tmux prefix in WSL2 without issue.

Re: Terminal Support for Emoji

#129

Post by rivo »

Per_Bothner wrote: post #104
rivo wrote: post #80

Earlier quoted context omitted.

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…

To my knowledge, there is no specification for monospace width. Applying the East Asian Width attribute as a proxy does not work reliably. So in my opinion, it is all a matter of agreeing on what's reasonable while keeping it simple. I.e. if allocating text-presentation Pictographics to a width of 1 is reasonable, that's what renderers should do. It's what users would expect.
Post reply on HN