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.
Terminal Support for Emoji
101–110 of 129 posts
Re: Terminal Support for Emoji
#102Interestingly, 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
#103Are 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.
Re: Terminal Support for Emoji
#104I'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.
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
#105Re: Terminal Support for Emoji
#106Earlier quoted context omitted.
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
#107I 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.
Re: Terminal Support for Emoji
#108I 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…
Re: Terminal Support for Emoji
#109Are 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.