[Bug Report] Markdown API does not parse emoji

[meteorlxy]

• Gitea version (or commit ref): try.gitea.io
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant

Description

https://try.gitea.io/api/v1/markdown does not parse emoji in markdown text.

For reference, here is what GitLab's markdown API returns:

[mrsdizzie]

I believe the two main issues here are

The library we use for Markdown processing has no type of emoji translation support: https://github.com/russross/blackfriday

That alone is probably a blocker on this (unless somebody provided that feature upstream).

We also use a Javascript library for this in the Web interface (https://github.com/joypixels/emojify.js) to render :smile: type text browser side (with static images). Making a change to the API output would alter how the Web interface currently works. I believe the goal was to move to another Javascript solution on the future, which would also maybe leave this feature out of the API.

An alternative to do this in the Markdown API would be to use a different Go Library for this type of emoji processing, and parse the text ourselves like we do for other things (issue links, sha, email address, etc...). I'm not aware of any libraries that will take a text like :smile: and output html however. Gitlab uses this Ruby Gem: https://github.com/bonusly/gemojione so there would need to be something similar for Go.

[silverwind]

Imho, if unicode emoji characters work, it's fine. Things like :smile: are non-standard and only work on a few specific pieces of software, unicode is supposed to work everywhere.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[6543]

@zeripath does goldmark handle this different? (#9533)

[zeripath]

I don't think it does out of the box - however, it should be quite easy to make it do it. There's a potential time cost to doing the rendering I guess would have to look up the strings in some sort of map.

Do you know does the :wibble: syntax conflict any other markdown? I don't think it does.

[guillep2k]

Do you know does the :wibble: syntax conflict any other markdown? I don't think it does.

BTW, I've been meaning to propose a new column (or table) for issues and comments containing the pre-rendered content plus references (mentions) and such. It should hold the rendered version of the content as long as it's shorter than a certain limit (the majority of comments will fall way below that limit). Anything bigger than that limit will be processed online, which is slower, but we're doing that already anyway. Thus we can worry less about the amount of processing in the output.

I'm not sure it's justified, but I thought I would mention it.