当启用“启用表情符号快捷方式”设置时，像 :) 这样的表情符号会被转换为实际的表情符号（
）。然而，无法通过在前面添加简单的反斜杠（\:)）来绕过此行为。这与其他支持转义的情况不一致；而在 Discord 上，你也有类似的设置：
但该设置并非强制性的——如果我想以原始形式显示 :-)，只需在其前输入一个反斜杠，即可得到我想要的结果。
要绕过此限制，你需要在中间使用零宽字符，或者将某个字母用尖括号包裹（因为它们不会渲染），例如：
:\u003cg\u003e), :)
这给希望更自由地书写表情符号的用户带来了不良的用户体验。
这不仅仅是快捷键，它全是表情符号。我想，如果我们前面有反斜杠，我并不反对修改它，从而停止将表情符号化。
所以：
\:thinking: 与 \`thinking` 和 \*thinking* 具有同等地位
与 `thinking` 和 *thinking* 具有同等地位。
我在 Roblox 开发者论坛（基于 Discourse 构建）上发了一篇关于这个话题的帖子。我同意，必须一直使用空白字符或其他方式来避免使用表情符号确实有点烦人；表情符号通常会让你的帖子显得不够专业，但有时候你只是想表达一个小小的 :)，而不想要一个 :)。
我希望这个问题能得到解决。（“我猜既然它是开源的，可能就不会更新了。”）
其实我找到这个话题是因为我自己也遇到了同样的问题（本想转义表情符号，结果它却变成了 emoji，还把转义字符给“吞”了……真是胆大包天，哈哈）
我们已有通过反引号实现的变通方案，例如 :-) 和 :)，还有代码块。不太确定是否还需要更多方法来实现同样的目标？
我的观点更多是关于在实际对话中使用表情符号，如果表情符号前加了反斜杠，不渲染表情符号而将其保留为表情字符，这不就行了吗？
`` 用于行内代码，如果你不是在讨论编程，使用代码块就没有意义。即使是在编程讨论中，行内代码通常也仅用于高亮单行代码或类/成员名称等，因此这样做仍然不合理。
并非如此——例如，如果你输入 <a>，HTML 会尝试渲染它。因此，行内代码块是渲染此类内容的预期方式。
我只是不确定是否值得将宝贵的工程时间耗费在已经拥有解决方案的事情上。
我在此标记欢迎提交 PR，我花了 15 分钟查看，发现没有简单的修复方案。
我们的解析器会吞掉转义码，所以等到我们拿到数据时，已经无法知道那里曾经存在转义符了。
无论这里有什么修复方案，都涉及对 markdown-it 进行 hack 并向上游提交补丁。这非常非常复杂……cc @Vitaly
在 https://markdown-it.github.io/ 也存在同样的问题。
建议你们向上游提交工单，尽管这可能意味着我们需要为文本令牌添加“该文本令牌的原始原始内容”注解。
此问题的难度等级约为 95。
此 bug 与“下划线可能破坏自动链接”存在类似的设计缺陷，但可能是特定的临时解决方案。我将查看可以做什么。
已创建问题：Postpone escape info drop · Issue #840 · markdown-it/markdown-it · GitHub
我必须全心全意地反对。“:)” 根本不像 :\u003cg\u003e)。
尽管如此，我还是同意这不值得浪费时间和金钱。令人讨厌，但可以理解。
看起来 @Vitaly 在 v13 中修复了这个问题，我们将升级到该版本
我的论坛上有一位用户抱怨这个格式问题，我已经禁用了表情符号自动补全作为我们用例的修复方法，但自从 Discourse 升级到 markdown-it v13 以来，这个问题似乎仍然存在，而在 https://markdown-it.github.io/ 上反斜杠转义现在可以正常工作了。
这是否是因为 ember.js 仍然依赖 markdown v12，正如这里所示？
我们现在是 13 版，据我所知…… cc @david 并且问题仍然存在。
哦，所以这应该相当容易修复（俗话说的“最后的豪言壮语”）
我现在就开始处理。
编辑：这可能比我想象的要难。 
