Replace emojify.js with openmoji set

[sapk]

emojify.js is not maintained anymore.

At some point we would need to switch to another lib to manage emoji (or maintain a fork).
The lib emojify.js does two think :

• replace :emoji: with tag
• provide a set of emoji

I suggest to move to openmoji for the emoji set.

It seems to be a large choice with good quality : https://openmoji.org/library/

[6543]

Not bad, but we ned to write own code - openmoji is no drop in place solution it is only a colection of emojis

[sapk]

@6543 Yes, that why I distinguish the two roles of emojify.

I wanted to let the first point up to discussion as I don't know if there is a lib that do it. Otherwise, I would plan on forking emojify based on openmoji set + capacity to add specific emoji like the gitea one at "runtime".

[silverwind]

I think a custom implementation is the way to go, backed by a minimal name-to-unicode map like https://github.com/muan/emojilib. Most modern browser support unicode emoji so we could get away with just supporting unicode (+custom graphics).

If image fallbacks are still desirable, maybe https://github.com/iamcal/js-emoji.

[silverwind]

On a sidenote, emojilib is probably too big to be included:

https://bundlephobia.com/result?p=emojilib@2.4.0

I guess we'd need something more trimmed down with just name to unicode maps without the extra fluff.

[lafriks]

I don't think we can use openmoji as it is licensed under cc-by-sa 4.0 that is compatible only with GPLv3 if I understand it correctly :(

[sapk]

@lafriks They mention that it just need a mention somewhere https://github.com/hfg-gmuend/openmoji/blob/master/README.md#attribution-requirements
But I understand that it is not compatible on code-source with MIT but it would be compatible with distributing along. It just don't have to be under the MIT license and in gitea code.

[guillep2k]

I don't have any opinions about which emoji library to use, but regarding how to implement it, I'd advise against parsing the emoji on the server (when comments are submitted or when the comments are rendered), i.e. I'm in favor of on-the-fly emoji detection that the user can control and nullify (e.g. using backspace). My reasons:

• I never hit the right name for an emoji except the most basic 😁. Relying on the submitted message to check whether I've typed in the right name will be very frustrating and lead to a lot of editions.
• The user will have to be extra careful to avoid typing anything that will become an emoji without realizing it. Furthermore, as we won't have control on the actual names for the emojis (they will come from a lib), we'll be hacking awfully to circunvent some annoying case.
• The escaping to avoid emojization (e.g. \:flags: vs. :flags:) is yet one more syntax to learn and it's not really Markdown. We should support escaping if we force emojization.

[silverwind]

Another question we have to ask is whether we want to store emoji as unicode in the database. I think GitHub does it that way and it would make data more portable at the expense of requiring the user to have Unicode support in the DB which may not be given on older MySQL installations.

[6543]

@silverwind I would prevere the :keyword: being stored in the DB as it is now

[sapk]

We could support both if we used the openmoji font (or any other emoji font) and replace in ui :keyword: with unicode. The :keyword: format is also used in commit message generally. This will also assure backward compat. This could also be implemented in the markdown rendering.