Markdown 降价和换行

大多数时候，降价文件就像源代码一样处理：它们在VCS中，它们参与拉取请求和/或审核，并且格式良好。就像在源代码中一样，我经常看到插入的换行符具有特定的长度，就像代码格式化程序那样

许多编辑器根据当前窗口大小（也称为word wrap）动态地执行此操作。此外，标记主要用于生成HTML页面、PDF文档或其他格式。在这些情况下，手动插入的换行符通常会导致文本呈现混乱

特定线长度的包装降价是好还是坏？主题似乎是，即使是当前的CommonMark规范（）也有些悬而未决：

规则的换行符（不在代码范围或HTML标记中）前面没有两个或多个空格或反斜杠，被解析为一个空格。（软中断可以在HTML中以A或空格形式呈现。在浏览器中的结果相同。在这里的示例中，将使用A。）

[……]

一致性解析器可以将HTML中的软换行符呈现为换行符或空格

渲染器还可以提供将软线打断渲染为硬线打断的选项

然而，早在2004年：

“一行或多行连续文本”规则的含义是，标记支持“硬包装”文本段落。这与大多数其他文本到HTML格式化程序（包括Movable Type的“转换换行符”选项）有很大不同，后者将段落中的每一个换行符转换为一个

标记

如果确实要使用标记插入一个

中断标记，请在一行末尾加上两个或多个空格，然后键入return

是的，创建一个

需要更多的努力，但是一个简单的“每一个换行符都是一个

”规则不适用于降价。Markdown的电子邮件样式的区块引用和多段落列表项在您使用硬分隔符格式化它们时效果最好，看起来也更好

---

大多数降价渲染器都会忽略单个换行符，因此围绕商定的长度包装文本不会影响渲染结果

然而，这可能会使代码更易于维护

因此，它不是一种反模式，一些项目甚至在其编码标准中需要它。示例来自：

---

好坏总是取决于你的观点和背景

在我自己改变了偏好之后，我认为主要的区别在于你是否将它们存储在像git这样的VCS中，或者如果你只是为了“个人使用”而写和读它们

使用“每行一句话”会使“语义”有所不同，因为它只会影响更改的行/句子。将整个段落重新格式化并显示在git diff中是。。。嗯，不太好。它使用“表示”隐藏实际更改

如果这不是一个问题的话，有时较长且参差不齐的行会使阅读和写作变得不那么愉快，因此在Wiki、电子邮件等网站中，我倾向于自动回流并限制行数，就好像我在哪里打字一样

标记实际上不是表示，而是源代码，因此，如果版本控制更重要的话，我们不应该太在意源代码的可读性

---

但“markdown is source”视图的一个警告是，并非所有渲染都以文本作为段落渲染两行，而是将换行符保留为“硬换行符”，导致结果在视觉上也不具吸引力。

虽然GitHub似乎确实忽略了单换行符（请参阅），但Pandoc不会忽略它们（示例命令

pandoc--自包含--来自markdown\u github

）.但可能有个标志。@beatngu13你找到这个标志了吗？我被

pandoc

here@javadba根据，现在有了

--wrap=auto | none | preserve

。但是使用默认设置，我再也不会得到与上述要点不同的输出：

pandoc——自包含的——从gfm到html5--output test.htmlhttps://gist.githubusercontent.com/beatngu13/754ceec042709e23d7945d3a953c2461/raw/e0c1e7465d68ba4f407a68eb3dabdeb237e255a4/markdown-and-line-wrapping.md

。

" Set text width as 72.
autocmd Filetype markdown set tw=72