[Bug Report] Markdown API does not parse emoji #3193

New Issue

GiteaMirror · 2025-11-02T05:03:25-06:00

GiteaMirror commented

2025-11-02 05:03:25 -06:00

Originally created by @meteorlxy on GitHub (Apr 15, 2019).

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:

Originally created by @meteorlxy on GitHub (Apr 15, 2019).   - Gitea version (or commit ref): try.gitea.io - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (provide example URL) - [ ] No - [ ] Not relevant ## Description `https://try.gitea.io/api/v1/markdown` does not parse emoji in markdown text. ![image](https://user-images.githubusercontent.com/18205362/56115875-062fb100-5f97-11e9-8db0-51c8f2462752.png) For reference, here is what GitLab's markdown API returns: ![image](https://user-images.githubusercontent.com/18205362/56116010-5444b480-5f97-11e9-889c-345c2d05ff67.png)

GiteaMirror added the issue/confirmed type/enhancement modifies/api labels 2025-11-02 05:03:25 -06:00

GiteaMirror closed this issue

2025-11-02 05:03:26 -06:00

GiteaMirror commented

2025-11-02 05:03:26 -06:00

@mrsdizzie commented on GitHub (Apr 15, 2019):

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.

@mrsdizzie commented on GitHub (Apr 15, 2019): 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.

GiteaMirror commented

2025-11-02 05:03:26 -06:00

@silverwind commented on GitHub (Apr 16, 2019):

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.

@silverwind commented on GitHub (Apr 16, 2019): 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.

GiteaMirror commented

2025-11-02 05:03:27 -06:00

@stale[bot] commented on GitHub (Jun 15, 2019):

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.

@stale[bot] commented on GitHub (Jun 15, 2019): 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.

GiteaMirror commented

2025-11-02 05:03:27 -06:00

@6543 commented on GitHub (Dec 30, 2019):

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

@6543 commented on GitHub (Dec 30, 2019): @zeripath does goldmark handle *this* different? (#9533)

GiteaMirror commented

2025-11-02 05:03:27 -06:00

@zeripath commented on GitHub (Dec 30, 2019):

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.

@zeripath commented on GitHub (Dec 30, 2019): 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.

GiteaMirror commented

2025-11-02 05:03:27 -06:00

@guillep2k commented on GitHub (Jan 8, 2020):

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.

@guillep2k commented on GitHub (Jan 8, 2020): > > > 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.

GiteaMirror referenced this issue

2025-11-02 12:19:54 -06:00

[PR #3193] [MERGED] Improve suppressed diff boxes #16822

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3193