Adding variation selector 15 to footnoteReturnLinkContents

In the Hugo docs, I see footnoteReturnLinkContents: "↩" a fair bit. Unfortunately, it’s not a particularly good suggestion because some OSs like Windows and iOS will render that particular character with emoji presentation, as ↩️. (To force emoji presentation here, I/macOS appended variation selector 16 after U+21A9.)

A few minutes ago, I thought it’d be a good idea to have the default be “\u21a9\ufe0e” instead of “↩︎” so Hugo users don’t need to look up the obscure topic of variation selectors. However, when I made a new Hugo site just now with a default configuration file, the default link contents ("" in Hugo code) is <sup>[return]</sup>. This would be a larger change than I expected.

Still, with U+21A9 LEFTWARDS ARROW WITH HOOK as a fairly popular return character, shouldn’t we join Pandoc in automatically suppressing emoji presentation by default? The following one-line change does it, even though we/I ought to change the docs to match:

diff --git a/hugolib/config.go b/hugolib/config.go
index 50e4ca6e..9c57ba24 100644
--- a/hugolib/config.go
+++ b/hugolib/config.go
@@ -613,7 +613,7 @@ func loadDefaultSettingsFor(v *viper.Viper) error {
 	v.SetDefault("pluralizeListTitles", true)
 	v.SetDefault("forceSyncStatic", false)
 	v.SetDefault("footnoteAnchorPrefix", "")
-	v.SetDefault("footnoteReturnLinkContents", "")
+	v.SetDefault("footnoteReturnLinkContents", "\u21a9\ufe0e")
 	v.SetDefault("newContentEditor", "")
 	v.SetDefault("paginate", 10)
 	v.SetDefault("paginatePath", "page")

Edit: I just noticed that Discourse itself mangled the emoji and LEFTWARDS ARROW WITH HOOK because it assumes, reasonably enough, that most people want emoji presentation for that character. If my meaning’s still unclear despite Discourse mangling my post I’ll be happy to clarify.

Second edit: maiki fixed the autoemojification problems mentioned in my "Edit: " paragraph above. Thanks, maiki!

That is not a default in Hugo.

footnoteReturnLinkContents is a configuration parameter that can be set as a user wishes.

Hugo does not set it by default. The search results you linked to are a mix of Hugo source code and content files from the Docs. In the latter the arrow is used because that is what has been decided for use by the Hugo Docs authors.

I don’t think that Hugo should impose a default for footnote return links.

Also enableEmoji (another configuration setting that can be viewed in the above link) is set to false by default. A user needs to enable emojis in a project’s config for Hugo to render emojis.

1 Like

It’s true that Hugo doesn’t change blackfriday’s default (in Hugo, the default is just "". blackfriday understands this as “unset”). Still, there is a default in the sense of “this thing will happen unless explicitly overridden by Hugo or a site’s Hugo config”. Since there is a default, I think it ought to be improved upon. At the very least, the docs ought to put VS15s in with the return arrows to save new authors the hassle of trying to find out why they’re getting emojis in iOS even though they’re not using emoji-looking arrows on their desktop computers.

Actually not true. enableEmoji appears to get Hugo to turn strings like : heart : into :heart:. However, I’ve typed emoji directly into Markdown documents and Go templates myself and gotten emoji in the output HTML without any problems. Similarly, leaving enableEmoji unset/false doesn’t turn on any emoji-stripping functionality in Hugo or blackfriday.

Edit: Linked to the part of blackfriday that adds in <sup>[return]</sup> if not explicitly overridden.

What you write above sounds like a GitHub issue that belongs to the Blackfriday repo. If you think this is something that really needs to be addressed here is the repo: GitHub - russross/blackfriday: Blackfriday: a markdown processor for Go

You should use a dedicated emoji font because there are bound to be raw emoji codes for certain characters in HTML output without one.

How exactly do you propose to do that? Currently most browsers render Unicode emoji out-of-the-box when the code is detected.

True.