コードブロックは、メールの HTML 部分においてのみ、各行の間に空の改行が含まれて表示されるようです。フォーラム自体やメールのプレーンテキスト部分では正しく表示されています。これはメールのフォーマットや CSS の問題ではなく、メールの場合にのみソースに実際の改行が挿入されていることが原因です。
例：[iFFT Freeze/Scrub - #25 by toneburst - Questions - scsynth]
投稿の元のソーステキストは以下のようになります：
ウェブサイトのフォーマットされた投稿は以下のようになります：
しかし、受信した HTML メールでは以下のようになります：
メールのソースを確認すると、すべての改行が二重になっていることがわかります：
同意します。これはかなり不自然に見えます。
@techAPJ 調査していただけますか？
2.9.0.beta1 から送信されたメールで問題が引き続き発生しています。それ以降に修正されている場合は、このメッセージの残りは無視してください 
これは特定のメールクライアントに関連する問題ではありません。2番目のスクリーンショットは、メール用に生成されている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;">=0D
// This expects two keys to be defined: ~history (the list) and ~recordKey (which key to record)=0D
Pdef(\keyRecorder, Pbind(=0D
\callback, Pfunc({=0D
|event|=0D
event[\callback].addFunc({ // combine your record func with any previous callback that was there (it's okay if its nil)=0D
~history.add(currentEnvironment[~recordKey])=0D
}).postln;=0D
})=0D
));=0D
=0D
明確に、(a) コード内の改行があるべき場所に実際の改行があり、(b) 各行の末尾に=0D（キャリッジリターン）文字があります。私の知る限り、<pre>内のすべての改行は文字通り解釈されるはずであり、これが二重改行を説明しています。
Gmailでこの問題を再現でき、メールメッセージのHTML部分をブラウザで直接開く（=0Dのような引用符付き印刷文字を置き換えた後）ことでも再現できます。これにより、疑問が生じます。
=0D）が見えますか？=0D（または改行）を何らかの方法で削除していますか？いずれにしても、Gmail固有の問題であったとしても、Gmailは圧倒的に最も一般的なメールクライアントであるため、少なくとも調べる価値はあるでしょう。