Closed jmooring closed 8 months ago
Having a way to escape emojis in code as on GitHub (where :grin:
won't be rendered as :grin:) would be nice indeed.
I suppose we can already do that with HTML entities but it's a few more characters to type. :slightly_smiling_face:
Workaround per @maelle: use :grin:
instead of :grin:
in your markdown.
Uh, no. Not within code blocks. Not enough coffee...
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 :smile:
Here's my original issue:
I have a table full of MAC addresses, some of them containing e.g. :de:
which gets translated to :de:, 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
Either set enableEmoji = false
in site configuration, or insert a zero-width space between the colon and the string.
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...
@cobber Inserting invisible characters is a particularly poor idea. Sorry about that. Seemed like a good idea at the time...
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.
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 }}
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.
I looked into the yuin/goldmark-emoji extension:
[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.
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.
What version of Hugo are you using (
hugo version
)?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...