Emojis are very important part of any discussion and forum, nowadays. I'm :dissapointed: to see that Emoji codes autocomplete is not supported in these Swift Forums.
Discourse supports Emoji codes autocomplete by default. Was the removal of this feature a deliberate decision? If yes, is it temporary or there are no plans to add the support back in the future?
Keeping my :fingers_crossed: to have them back.
It was recently disabled because Swift often uses spellings such as foo(bar:). Without code voice, these get turned into happy faces, greatly impeding discussion.
You can still insert emoji via your own device's input methods.
Doesn’t wrapping code in backticks make it not render an emoji?
Yes, that's "code voice." Not all use it consistently or want to, and quoting a post with code voice in Discourse removes the backticks. So it was requested to disable automatic emoji features.
This sounds like a bug with Discourse, or at least unintended behavior.
That's not a solid argument for me. Take a look at GitHub. It's a much bigger site with much more code-oriented discussions. And yet it manages to both enforce code voice and support emoji codes.
Although I agree that it's unintended behavior, this is a solid argument against supporting emoji codes for me.
I agree. Emoji were disabled after single request based off a post not using proper code styling. They should be turned back on.
Github does not turn "foo(bar:)" into "foo(bar😀"
Neither does Discourse, if the code is properly styled, as it should be for readability anyway.
That much has been clearly stated above. You know full well that the point being made is that GitHub does not turn plain text "foo(bar:)" into a string with emoji, but Discourse does. This is not conducive to a productive discussion.
A question was asked, and I answered it. For clarity: the reason that emoji autocomplete is disabled here is because it's tied to autotranslating plain text to emoji; it has been pointed out that the latter behavior gets in the way of discussion, and it is not a feature found on GitHub, where emoji autocomplete is still available.
We use CommonMark here and any code wrapped in ` ` is treated as preformatted text including
code that is in
quotes :)<= I am code
I guess the feature request is to disable shortcode emojis so we don't turn :) into a smiley face even if its not preformatted. Totally open to adding this as a site setting, just have the @forum_admins raise it with us.
Hi Sam, consider it raised :-)
Consider it built, will be deployed here later today:
https://github.com/discourse/discourse/commit/3492a9105671c6795f4b92f54d9b88f93def4105
Also is there a reason oneboxes to Github are disabled?
Awesome, thanks!
I'll pm you about onebox.
Now that several weeks have passed since the ability to disable shortcode emojis was added to Discourse, should all emoji codes still appear in plain text on the site? For example, this is what @sam.saffron's comment looks like to me:
Is this expected behavior? If not, is there any timeline for automatically converting long emoji codes like :smile: into ?
I just turned on emojis here with @Nicole_Jacque's permission!
Enjoy the amazing new emojis (btw I picked the Apple emoji set for max consistency) 
(:v:t3: - a 
using tone 3)
:) ;) etc will no longer get in the way.
I do want to refine it though so we are a bit smarter about disabling autocomplete right after you type ``` so it has less chances of being confusing in code blocks.
Thanks Sam! 
i never knew emoji codes were a thing
Do you know when you're going to support the latest emoji? I tried to use https://emojipedia.org/woman-zombie/ in a thread as an example of how Unicode encodes emoji, and it didn't render 
Out of curiosity, what the pro of using emoji code while you can simply use 
?
Edit: Funny. In the edit box my emoji properly render as a zombi woman, while in the forum it renders as a zombie man followed by a 
variant. At least, it answers my question ;-)
