代码块似乎仅在电子邮件的 HTML 部分中，每行之间都带有空行。它们在论坛本身以及电子邮件的纯文本部分显示正常。这不是电子邮件格式或 CSS 问题——仅在电子邮件情况下，源文本中实际插入了换行符。
示例：[iFFT Freeze/Scrub - #25 by toneburst - Questions - scsynth]
帖子的原始源文本如下：
网站上的格式化帖子显示如下：
然而，收到的 HTML 电子邮件显示如下：
在电子邮件的源文本中，您可以看到所有换行符都变成了双倍：
4 个赞
我同意，这看起来确实有些不对劲。
@techAPJ 能否调查一下？
3 个赞
我仍然看到 2.9.0.beta1 发送的电子邮件存在问题 - 如果在此之后已修复，请忽略此消息 
这与特定的电子邮件客户端无关 - 我发布的第二个截图是为电子邮件生成的原始 HTML。但实际上，查看实际电子邮件内容（摘录…）更有启发性：
<pre style="word-wrap: break-word; max-width: 694px;"><code style="display: block; background-color: #f9f9f9; overflow: auto; padding: 5px;; background-color: #f9f9f9; padding: 2px 5px;">
(
// This expects two keys to be defined: ~history (the list) and ~recordKey (which key to record)
Pdef(\keyRecorder, Pbind(
\callback, Pfunc({
|event|
event[\callback].addFunc({ // combine your record func with any previous callback that was there (it's okay if its nil)
~history.add(currentEnvironment[~recordKey])
}).postln;
})
));
很明显，存在 (a) 实际的换行符，其中代码中应该有换行符，以及 (b) 每行末尾的 =0D 字符（回车符）。据我所知，<pre> 中的所有换行符都应被视为字面量，这解释了双换行符。
我可以在 Gmail 中重现此问题，并且可以通过直接在浏览器中打开电子邮件消息的 HTML 部分来重现（在替换了 =0D 等引用的可打印字符之后）。这让我很好奇：
- 当您查看您发布的电子邮件的原始版本时，是否也看到了相同的（换行符加上
=0D）？ - 如果是这样，您发布的“正确”视图的 HTML 源代码是什么样的？您的电子邮件客户端是否以某种方式剥离了
=0D（或换行符）？
无论如何，即使这是 Gmail 的特定问题，也可能值得研究一下，因为 Gmail 是迄今为止最常见的电子邮件客户端。