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

Gitmoji – Yay or Nay?

opensource.christmas

Post reply on HN
Print view View original

71–80 of 224 posts

Re: Gitmoji – Yay or Nay?

#71

Post by WalterBright »

Aeolun wrote: post #69
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…

> [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 days at Symantec, the people making the IDE worked hard to come up with icons. They had a problem finding an icon to represent a CPU register, and finally settled on a picture of a cash register.

Re: Gitmoji – Yay or Nay?

#72

Post by knolax »

Iv wrote: post #36
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…

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

I once had an issue where GTK-2 couldn't display any characters that were in ASCII/latin basic. It was down to Pango dropping support for the monospace font I used for that range of characters. In my opinion the most reliable part of your system is the part you put the most attention on. ASCII is only the most reliable if you choose to use it as the basis for your system and then ignore support for everything else.

Although I do agree the one character to one codepoint mapping of ASCII is useful, things like terminal escape codes already add a layer of complexity that makes it hard for me to imagine a scenario where you can't render U+1F4A9 but can still render things like ^[[31m found in almost every cli tool.

Re: Gitmoji – Yay or Nay?

#73

Post by DagAgren »

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…

Ironically, you can't even write proper English in ASCII. It is missing many characters widely used in English text.

Re: Gitmoji – Yay or Nay?

#74

Post by DagAgren »

rahuldottech wrote: post #61
porker wrote: post #16

Earlier quoted context omitted.

> Emoji are hard to type on non-mobile platforms On Windows they are easy: + . Finding the right emoji is easier than on my Android phone as Windows lets me type the emoji name. Why emoji search is missing on Android... who knows.

A decent chunk of programmers use GNU/Linux distros. Support is very lacking there.

"Programmers don't like this because Linux is shit" isn't a great argument against anything, really.

Re: Gitmoji – Yay or Nay?

#75

Post by bitcoinofficial »

fbnlsr wrote: post #41
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…

Wait, I thought the goal of it is not to write emojis per se but rather use the shortcodes. That way, it's readable even when emojis cannot be rendered and it even makes search easier. So a typical commit message would read like that: `:bug: Fix login modal` It doesn't break anything and when interpreted (github, gitlab, gitkraken, etc...) it displays a nice looking emoji.

Doesn't 'fix' already mean there was a bug, that was 'fix'-ed?

Re: Gitmoji – Yay or Nay?

#77

Post by LockAndLol »

That would require linux distros to distribute some kind of tool to display them properly and enter them easily in the CLI as well as IDEs.

This is what it looks like to me:

- [CLI](http://i.imgur.com/XMcXwvi.png)

- [Pycharm](http://i.imgur.com/HOXj2yg.png)

Even displaying that recycle emoji required me to install some font from a repo on github. Emojis seem to have very poor support on linux.

If [this method](http://i.imgur.com/v5eqgSJ.png) of entry were standard then maybe it'd be interesting and I'd give it a try.

Given the current status of emoji support on linux, that's a big naw from me dawg

Re: Gitmoji – Yay or Nay?

#78

Post by johnisgood »

Absolutely not. Keep your emojis out of my CLI and my face, even, as far as professional areas of life are concerned. I see READMEs full of emojis, the description of the project is full of emojis... I personally dislike it, and it actually makes me reconsider digging more into that project. I might have prejudices, but it is quite childish to me. The only place where I am fine with emojis is instant messaging applications (for casual conversations). You can even have stickers there if you want for all I care!

Re: Gitmoji – Yay or Nay?

#79

Post by Liquidor »

bitcoinofficial wrote: post #75
fbnlsr wrote: post #41

Earlier quoted context omitted.

Wait, I thought the goal of it is not to write emojis per se but rather use the shortcodes. That way, it's readable even when emojis cannot be rendered and it even makes search easier. So a typical commit message would read like that: `:bug: Fix login modal` It doesn't break anything and when interpreted (github, gitlab, gitkraken, etc...) it displays a nice looking emoji.

Doesn't 'fix' already mean there was a bug, that was 'fix'-ed?

> Doesn't 'fix' already mean there was a bug, that was 'fix'-ed?

Read this: https://stackoverflow.com/questions/3580013/should-i-use-pas...

TLDR from the Git repo: Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behavior.

People have different opinions on what tense to use, but the one that scales better would be in imperative mood. See example here: https://github.com/facebook/react

Re: Gitmoji – Yay or Nay?

#80

Post by FroshKiller »

josteink wrote: post #51

Nay. I'm clearly against this, and I don't find this kind of addition to the git ecosystem productive. And hopefully that won't translate into me being "hostile" towards women in tech, just because this was proposed by a woman.

It wouldn't have even occurred to me if you hadn't specifically mentioned it, which now makes me suspect it does have something to do with the fact a woman proposed it.
Post reply on HN