📝 Explicitly document which emojis are working where and in which format

[KaKi87]

Hello @carloscuesta :sunglasses:!

In https://github.com/johannchopin/gitmoji-browser-extension/issues/5#issuecomment-654311545, @johannchopin rightfully stated :

not all tool support emoji shortcode (issue title for example) I always use the emoji directly instead of the shortcode

Perhaps it would be great to document in README or in wiki which emojis are working where and in which format.

For instance :

• only emoji works on GitHub issue/PR title
• both emoji and code work on GitHub issue/PR body
• both emoji and code work on commit message on GitHub, Gitea and GitHub Desktop
• only emoji works on bash but code works with emojify
• none work on bash for Windows

Etc.

I think we should document best-known platforms for git repositories, clients and shell interpreters/terminal emulators (don't know which is responsible exactly)

Thanks

[vhoyer]

I don't think thats a good ideia, we'd have to mantain a forever expanding list of places that it works or not.

For example, you can say that the emoji unicode works in the commit message, but in the company I work for, we had a problem with unicode in the message that was failing the build. So we'd have to have: "unicode works in commit messages, but if you use CIX you can't use it because it will break your build" (I don't know the CI, cuz it's long gone here)

[KaKi87]

Well, I personally would have liked to be warned about what doesn't work where. But, you know, we can add the "disclaimer : this information is provided without any warranty" etc.

[Lyokolux]

Perhaps it would be great to document in README or in wiki which emojis are working where and in which format. [...] I think we should document best-known platforms for git repositories, clients and shell interpreters/terminal emulators (don't know which is responsible exactly)

Seems to be too much work. Why not trying to give as much portability as we can ?

[KaKi87]

Seems to be too much work.

I'm volunteering.

I just want it to be officially supported, so it can help people for real, while doing something on my own won't be useful if no one sees it.

Why not trying to give as much portability as we can ?

We're already doing that. But for example the thing about emojis and codes isn't something you can just guess.

[vhoyer]

Well, ok, let's put this in the readme, then :D

[johannchopin]

@KaKi87 @vhoyer It would be better to write it in a separate .md file and linked it in the README. But honestly I don't really get the point of this feature 🤔 Are you going to look on every development tool to see if every gitmoji is supported? Does that mean that for every new tool you're going to have to test it? This seems like a titanic task

Moreover gitmojis are just emoji code so you could just as a user search if the tool support emoji code.

[carloscuesta]

I don't particularly think it's a great idea since this could be changing and we would end up with an outdated list of use cases. I think it's better to let the user figure out which format he wants