Gitmoji – Yay or Nay? • Hacker News Board

Re: Gitmoji – Yay or Nay?

#181

Post by Iv » Wed, Dec 11, 2019, 5:24 PM UTC

GeneralMaximus wrote: post #45

Iv wrote: post #36

Earlier quoted context omitted.

> Please use good ol' plaintext I want to emphasize on that. Why do programmers like plaintext, often to the point of wanting ASCII instead of unicode despite its international awesomeness? That's because we are called when things break down in the machinery. Monospace ASCII may look boring, but it has a precious characteristic: there is (almost) 1-to-1 mapping between the inner representation of a character and its…

Only programmers from English-speaking countries like ASCII. There are millions of us living in other countries who are thankful that Unicode exists, and who are constantly annoyed that a some of our tools don't support it well enough. As someone who grew up bilingual in a country where it's not uncommon for people to speak three or more languages, I hate the idea of being prevented from using one of the languages I…

As a non-native English programmer, I disagree. I love ASCII despite it lacking many characters from my own language. Sometimes Instead of the Ç I expect, I'll get a Chinese character. What do you do then? Well you switch to an ASCII-only mode and debug the encoding by looking at the bytes. You go one level of abstraction lower than the unicode.

The ability to do that is precious.

> If your app has no issues rendering हैकर न्यूज़ (Hacker News), then it should have no issues rendering Emoji

First, that's not true. Many fonts have partial support or an app may have an issue with displaying mutli-colored glyphs. There are many possibilities for this partial failure.

> then the problem is your app and not Unicode.

Yes. Precisely. I don't think unicode or emojis are problematic per se. But they belong to a higher layer than the one a lot of (non-web) programmers spend their times in. Unicode support is HARD. ASCII support is easy. Making ASCII tools is easy and promises an ecosystem full of useful tools.

> This is one reason I prefer using GUI applications over CLI applications: Unicode support is terrible across terminals and CLI apps, while most of the commonly used GUI frameworks are okay.

And that's fine, but realize that by doing so, you depend on a layer that relies on an ASCII layer. Tools that require unicode can't be used there.

Re: Gitmoji – Yay or Nay?

#182

Post by mook » Wed, Dec 11, 2019, 5:29 PM UTC

reaperducer wrote: post #172

rahuldottech wrote: post #3

That's a no from me. I am not a huge fan of emoji. Especially not in the cli or editor. Emoji are hard to type on non-mobile platforms, and are difficult to search for in logs or files. Often they don't render properly. They're near impossible to deal with from the command-line. Not to mention the accessibility issues. I see no reason why these cannot be accomplished with tags/flairs such as [critical], [bug], etc. T…

Emoji are hard to type on non-mobile platforms, and are difficult to search for in logs or files. Often they don't render properly. They're near impossible to deal with from the command-line. While I agree that emoji shouldn't be used in git, it's worth noting that the limitations you point out are platform-specific, and not universal. in macOS, emoji work very well in any app that chooses to allow them, including th…

> Typing emoji is as simple as double-clicking on the character you want from the pane that pops down from the menu bar.

… Which means getting your hands off the keyboard. That is why I don't like being forced to type emoji; it requires a (physical) context switch.

Re: Gitmoji – Yay or Nay?

#183

Post by shakna » Wed, Dec 11, 2019, 5:31 PM UTC

zamalek wrote: post #156

woodrowbarlow wrote: post #146

Earlier quoted context omitted.

> they don't degrade gracefully for blind users why not? there is a canonical plain-text description for every unicode emoji. at least in theory, i see no reason why a screen reader shouldn't be able to handle emojis.

Screen readers do handle emojis in this way, at least the Google assistant while I'm driving does.

Google Assistant is very far from most of the common screenreaders. Both in quality (better) and capability (worse).

JAWS has been known to crash when handed some unicode sequences. So now it simply ignores them and says nothing.

The alternatives tend to be worse than JAWS. Such as spelling out the codepoints in hex, or crashing before it gets anywhere near the unicode it doesn't understand.

Re: Gitmoji – Yay or Nay?

#184

Post by shakna » Wed, Dec 11, 2019, 5:35 PM UTC

woodrowbarlow wrote: post #146

danShumway wrote: post #137

I've gotten into arguments over whether or not emoji belong in the unicode standard at all, and I'm not going to rehash them here. What I am going to say is that regardless of whether or not emoji are a good fit for unicode, they don't degrade gracefully for blind users (or for sighted users on older hardware) and they're prone to rendering issues between different fonts that can mask intent.[0] Everything bad about…

> they don't degrade gracefully for blind users why not? there is a canonical plain-text description for every unicode emoji. at least in theory, i see no reason why a screen reader shouldn't be able to handle emojis.

In theory, there's nothing stopping them.

But in reality, they don't work. They don't work today, and they probably won't work next year. Heck, half of UTF-8 tends not to work.

Should a segment of the population that are forced to rely on poor tools (I hate JAWS so very very much) be excluded today?

Re: Gitmoji – Yay or Nay?

#185

Post by Iv » Wed, Dec 11, 2019, 5:36 PM UTC

nicoburns wrote: post #118

WalterBright wrote: post #68

Earlier quoted context omitted.

I was keying in my confirmation code into the self checkin machine to get my boarding pass the other day. The code was something like EFO123. Was that a letter or a digit? I got it wrong, fortunately the software said it interpreted 0 as O and gave me the ticket. Now multiply this by a thousand with Unicode exact lookalike glyphs.

Emoji like those in this article don't have this issue though.

You can still have problems with them. They propose to ID a commit type by the first character.

Arabic is written from right to left. Which emoji is the first character of this sequence? It actually depends on the position of invisible LTR control characters.

علامة يمين-إلى-يسا

EDIT: BTW, HN does not support emojis apparently

Re: Gitmoji – Yay or Nay?

#186

Post by tuwtuwtuwtuw » Wed, Dec 11, 2019, 5:42 PM UTC

nkrisc wrote: post #130

DagAgren wrote: post #123

Earlier quoted context omitted.

Accents and diacriticals are far from "hyper specialised", they are how many people are taught to write, and want to write. And - is not a dash, it is a minus. It does not suffice as a replacement for a real en or em dash in a properly typeset text. This is also not "specialised", it is how English is correctly typeset.

And yet accents and diacritical marks are not widely used nor any longer exclusively "proper." You're fighting a losing battle. Language is changing underneath you, no matter how tightly you cling to it.

What battle are you referring to? A large majority of the world's population is speaking languages containing characters outside of ASCII. ASCII has no relevant future.

Re: Gitmoji – Yay or Nay?

#187

Post by kps » Wed, Dec 11, 2019, 6:01 PM UTC

chrisseaton wrote: post #99

tadzik_ wrote: post #25

Nay, nay, nay. I don't like text that looks differently for everyone depending on the platform they're on. Emojis have shown us already that vendors are willing to change their appearance depending on current trends or political climate. Gun becomes water gun, salad becomes vegan salad. One day, if caterpillar becomes a butterfly because of some mundane idea, is it still going to be instantly recognizable as a bug? W…

> I don't like text that looks differently for everyone depending on the platform they're on. But we already have fonts that make the Latin alphabet look different on different platforms. > if caterpillar becomes a butterfly because of some mundane idea, is it still going to be instantly recognizable as a bug? Yes? Didn’t Hopper tape a moth ‘bug’ into her notebook?

> But we already have fonts that make the Latin alphabet look different on different platforms.

But the differences in appearance are abstracted away; the whole point of an alphabet is that it's a small fixed set of symbols. Conversely if you see 𓀪 on one platform and 𓀫 on another, you have no idea whether the difference is meaningful or decorative.

Re: Gitmoji – Yay or Nay?

#188

Post by cryptonector » Wed, Dec 11, 2019, 6:02 PM UTC

No.

Re: Gitmoji – Yay or Nay?

#189

Post by cryptonector » Wed, Dec 11, 2019, 6:04 PM UTC

WalterBright wrote: post #62

> With gitmoji others or your future self can simply look at the associated emoji and straightaway catch the intention. Just like a word does. > The [bug emoji] emoji is easily recognized as a bug by most people The word "bug" works for me. > but will [tulip emoji] immediately signalize that code is removed? Nope. Besides, we already have commonly used symbols for that, "+" for a line added and "-" for a line deleted…

Grepping for emoji is harder than grepping for words. Please no. No emoji in commit synopses. No!

Re: Gitmoji – Yay or Nay?

#190

Post by machello13 » Wed, Dec 11, 2019, 6:15 PM UTC

WalterBright wrote: post #71

Aeolun wrote: post #69

Earlier quoted context omitted.

> [tulip emoji] Is that what it looks like for you? For me it’s a flame (which seems to make more sense for removing code).

Yeah, it looks like a black tulip. As for a flame, I don't associate fire with removing things. Frankly, emoji and icons may work for things but they don't and never have worked for actions . Apple, for example, never did come up with an icon for "print" that people didn't have to be told what it meant. Apple could have saved a lot of grief by using "print" instead of the icon. (The same for "delete".) Back in my day…

> Apple, for example, never did come up with an icon for "print" that people didn't have to be told what it meant. Apple could have saved a lot of grief by using "print" instead of the icon. (The same for "delete".)

Do you have any references for this? Every print icon I've seen Apple use looks like a printer, and every delete icon looks like a trash can. Is there an article or something saying these caused confusion?