Emoji are rendered within code and code blocks

[jmooring]

What version of Hugo are you using (hugo version)?

$ hugo version
Hugo Static Site Generator v0.71.1/extended linux/amd64 BuildDate: 2020-05-25T13:06:06Z

Does this issue reproduce with the latest release?

Yes

Problem Description

Emoji strings with code (single backticks) or code blocks (triple backticks) are rendered to images. They should remain as strings.

By comparison, GitHub does not transform emoji strings when they appear in code.

I came across this problem while trying to document the use of emoji strings. Not very important...

[maelle]

Having a way to escape emojis in code as on GitHub (where :grin: won't be rendered as 😁) would be nice indeed.

[maelle]

I suppose we can already do that with HTML entities but it's a few more characters to type. 🙂

[jmooring]

Workaround per @maelle: use :grin: instead of :grin: in your markdown.

Uh, no. Not within code blocks. Not enough coffee...

[cobber]

I just posted this issue to goldmark-emoji and was promptly told to come back here :-|

goldmark is not dedicated for Hugo.
If you have an issue 'via' Hugo, Please submit issues in Hugo repository.

So here I am 😄

Here's my original issue:

I have a table full of MAC addresses, some of them containing e.g. :de: which gets translated to 🇩🇪, even though it is surrounded by back-ticks.

e.g.: (with fake data)

What I See	What I Expect
ab:cd:01:de:ef:02	ab:cd:01:de:ef:02

I have wrapped all of the data in backticks, but that has no effect on goldmark, but works here on github.

I have not found any way to disable the emojification, e.g. \:de: just adds a \ before the emoji, :\de: disables the emoji, but leaves a spurious \ in my data, killing copy-pastability.

I'm using goldmark v1.4.4 via Hugo v0.93.0

[jmooring]

Either set enableEmoji = false in site configuration, or insert a zero-width space between the colon and the string.

[cobber]

Either set enableEmoji = false in site configuration, or insert a zero-width space between the colon and the string.

As clever as those solutions might be...

• I don't want to have no emojis, just not in code blocks
• inserting invisible characters does not help when dealing with copy/paste-able data. That would result in data which looks ok but is silently and invisibly broken

[jmooring]

@cobber Inserting invisible characters is a particularly poor idea. Sorry about that. Seemed like a good idea at the time...

[jmooring]

The yuin/goldmark-emoji extension did not exist when emoji support was added to Hugo, and that extension seems to handle these cases as desired. We could retain our emojify template function, but replace everything else.

I do not understand what impact that would have on alternate content formats (HTML, adoc, org, etc.).

I'd love to make this somebody else's problem, particularly when the "somebody else" is yuin/goldmark. That project is exceptionally well-maintained.

[bobbygryzynger]

I worked around this particular issue by leaving emoji rendering off by default and adding an emoji shortcode.

Content:

{{< emoji ":+1:" >}}  Everything is A-OK. Carry on!

Shortcode (emoji.html):

{{ .Get 0 | emojify }}

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[jmooring]

I looked into the yuin/goldmark-emoji extension:

• It has full coverage of GitHub emojis (a few gaps will be filled when #5 is merged).
• Emoji shortcodes in code blocks, fenced code blocks, and inline code are not converted (what this issue is about)
• Adding 5 lines of code (excluding tests/docs) we can do:

[markup.goldmark.extensions]
emoji = true

But this is overridden if enableEmoji in the configuration root is true, and I think that's OK. We support emoji in markdown (goldmark), org mode, asciidoctor, pandoc, and rst. And we do that by parsing the content before we hand off to the renderer.

So, if you are only using emoji in markdown, the configuration would be:

enableEmoji = false # default is false

[markup.goldmark.extensions]
emoji = true # default is false

So, that's quick to do.

As a second and optional step, we could (perhaps) replace kyokomi/emoji with yuin/goldmark-emoji in hugo/helpers/emoji.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.