最佳实践：电子邮件中的 ASCII 分隔符？

支持
1

Discourse 社区的朋友们，大家好——

首先，感谢你们打造了这个我认为非常棒、实用、灵活且（大部分情况下）直观的工具。我们正计划将项目的多种沟通方式迁移到 Discourse，包括从基于用户的社区讨论邮件列表，到由脚本生成的通知邮件（用于报告关键事件，如新问题、测试失败等），我们对这些变化充满期待。

在设置过程中，我遇到的一个问题是：发送到 Discourse 的邮件中，----- 这类行之后的内容会被自动剥离。据我理解，这是为了避免通过邮件发布的帖子携带整个回复链。我也一直对基于邮件的回复在 Discourse 中的呈现效果印象深刻，因此在这个问题上，我完全认可这一设计选择。

我们传统上经常在这些脚本生成的通知邮件（现在正转发到 Discourse）中使用此类分隔符，以便无论使用传统还是现代技术，邮件都易于阅读。我目前正在移除这些分隔符，并尝试改用其他方法，比如“增加更多的垂直空白”。但在深入进行这项工作之前，我想确认一下：是否有其他建议的最佳实践，用于在发送给 Discourse 的邮件中创建此类分隔符？或者是否有办法转义它们，使其绕过当前的过滤器（我目前最好的尝试是使用 n 连字符而非连字符/ASCII 减号，但出于简洁考虑，我并不倾向于使用非 ASCII 字符）。

我们中的许多人还习惯在邮件中使用小小的 --- 分隔符来区分代码块或其他内容。因此，我担心即使我们完成了所有脚本生成消息的转换，这仍会影响那些依赖“回复”功能来响应转发到其收件箱的 Discourse 主题的用户（但这也许只是我们需要克服的一个学习曲线？）。

感谢大家提供任何提示或建议，
-Brad

2

啊哈……我自己刚发现的一个可能对找到这个帖子的其他人有帮助的技巧：在原本作为分隔符的行中混入非分隔符/标点符号的 ASCII 字符，可以使其通过 Discourse 的过滤。因此，将类似这样的行：

标题
--------------------------------

改为：

--- 标题 ---------------------

就是一种在避免被 Discourse 移除的同时保留某种分隔线形式的方法。当然，这仍然无法帮助那些习惯依赖简单的 ---- 分隔线来在邮件中区分内容的用户，所以我仍很好奇大家对此是否有推荐的最好做法。

3

冒着继续自言自语的风险，这里有一个我们今天遇到的具体激励性示例：

我们使用脚本通知人们事件的一个场景是：当新的 PR 合并到我们的 GitHub 仓库时，向开发人员发送邮件。现在，我们已经将这些脚本改为向 Discourse 网站上的特定类别发送邮件。然而，由于 GitHub 使用 Markdown 来描述 PR，我们的 PR 描述中经常会出现如下所示的章节标题：

此 PR 的详细信息
------------------

这些标题在 GitHub 上会被渲染为章节标题。但当邮件发送到 Discourse 时，这一行破折号会导致邮件的其余部分被截断。

我们当然可以培训所有开发人员使用其他不会被截断的标题样式（例如 ## 此 PR 的详细信息），但如果有一种方法可以修改我们的脚本，以处理合并消息并保护或转义此类模式，使其能够完整保留到 Discourse 中，那似乎更具吸引力。