Testing… 编辑器始终显示与主题帖子中渲染的内容不同 [1] markdown: [^note] + [^note]: 这应该是一个脚注。。
在测试帖子中 在 discourse.python.org 上，将插入符号放在方括号内或外都会产生一个内联注释 [2] markdown: ^[this is coded as an inline note]。
……这里也发生了同样的事情。在 discourse.python.org 上当前激活的深色主题中，它在编辑器的预览窗格中看起来很棒，但在帖子中渲染效果不佳。（尽管超链接也显得非常暗且小。）
我想我将使用折叠下拉菜单 \u003c1\u003e。
因为我可以将它们放在与额外信息相关的段落后面——而且它们在折叠时，可能比长脚注占用的行数更少。（我尝试在“1”周围使用方括号，但无法弄清楚如何转义方括号，以免它们混淆 markdown 解释器。）
我们在 discuss.python.org 网站上为此感到困扰。
Discourse 的补充注释选项可以增强其深度丰富性。但成功的实现有一些关键点。
与理想状态的主要区别在于使用“footnote”（脚注）一词来表示明显不是脚注的东西。**inline note（行内注释）是行内的，而 footnote（脚注）则位于页面底部（在我们的例子中，是消息的底部）。
这凸显了第二个区别：脚注和行内注释是两种截然不同的注释类型，它们有明显不同的用例和有效使用方法。因此，它们应该是独立的功能，并可能由独立的配置变量集控制。
通过更改插入符位置的选项，用户可以决定是使用原地展开（行内注释）还是远程引用（脚注）。目前，这两种构造都生成行内注释。我们觉得这有点令人费解，尽管将大段注释文本放在消息底部而不是让它干扰正文编辑器中的正文文本是很有用的。
无论如何，我们 discuss.python.org 的人非常希望能够同时使用行内注释和脚注。这将扩展精心撰写的主题帖的吸引力。
一种选择是将插入符的位置设为两个不同的开关：
^[txt] 创建行内注释。
[^lbl] 创建脚注。
^[^lbl] 创建一个行内注释，其注释文本位于显示位置的远程位置。
这两种补充文本项的通用名称是“Annotations”（注释）。
我认为这最好首先作为 CommonMark 规范的一部分来解决。请参阅上面链接的 https://talk.commonmark.org/t/how-should-footnotes-behave/1106。
同意，马修。感谢您强调这些参考资料。不幸的是，这些参考资料有点少，而且我在这里没有找到更好的主题。也许 CommonMark.org 有更近期的讨论。
是的，已解决。不过，我首先需要弄清楚如何以及向 CommonMark 呈现情况。我在这里发帖是因为其他用户的输入将为将主题转发给 CommonMark 时的讨论提供信息。Discourse 也是我们作为用户的直接“父级”，Sam 等人可能想知道脚注的扩展实现对用户来说运行得有多好。
所以请分享您的想法——而且要快，因为这个主题有一个“垃圾处理”功能，会在 30 天后删除帖子！
@mlgtechuser，如果我理解正确的话，这可能是：
如果您尝试 discussion.fedoraproject.org/new-topic 并输入：
[^1]
[^1]: Content
……您可能会看到更符合预期的结果，因为脚注会呈现为参考文献（而不是仅在选择其内联数字引用时可见的内联框）。
否则，如果您要求两种模式共存，从而将一些“注释”呈现为附加在文档末尾的参考文献脚注，而其他则保持内联，我完全同意那将是现象级的。