为什么我喜欢这些标记语言

3 位读者喜欢这篇文章。
Typewriter keys

原始照片由 Bob Doran 通过 Flickr 提供。由 Rikki Endsley 修改。 CC BY-SA 2.0。

大约在去年的这个时候,我为本专栏撰写了一篇关于各种标记语言的简要介绍。最近,语言选择的话题被多次提及,所以我认为现在可能是时候更公开地带着我的偏见重新审视这个主题了。我在这里解释为什么我更喜欢我使用的语言,而不是为您开任何处方。毕竟,我不是医生。

一位同事询问了我对一篇比较 reStructuredText 和 Markdown 以进行技术文档撰写的文章的看法。我公司的文档是用 reStructuredText 编写的,并使用 Sphinx 渲染,但我时不时地表达过要转向类似 DocBook XML 的想法。对我来说,reStructuredText 处于反金发姑娘区域,它不像 Markdown 那样超级简单,但也不像 DocBook XML 那样丰富。它的闪光点在于使用 Sphinx 为 Python 自动生成模块文档

最近,Copyleft Guide 的主要维护者宣布他打算从 LaTeX 切换到 CommonMark 或 AsciiDoc。由于从未使用过 AsciiDoc,我有点惊讶于我如此强烈地为它辩护,但随着我进行了后续对话,我意识到它非常适合类似书籍的文档。

“将内容与演示文稿分离,”他们说。像 DocBook 和 AsciiDoc 这样的语言允许作者说,例如:“这是一个 GUI 按钮。”它最终可能会以粗体渲染,但您不仅仅添加 <em> 就完事了。内容与演示文稿分离;例如,像 Asciidoctor 这样的渲染工具使用层叠样式表 (CSS) 来控制演示文稿。

我在类似书籍的文档中最喜欢做的事情是包含标注。警告、提示等对您的读者来说是很重要的功能。在大多数情况下,读者最终会略读本书的某些部分,要么是因为他们正在寻找特定的部分,要么是因为您的散文太枯燥乏味而失去了兴趣。突出显示特别重要的部分有助于确保读者获得您真的非常希望他们知道的信息。此外,它们为成段的文字添加了很好的分隔。公平地说,reSTructuredText 对这些有一些支持,但我一直无法使它们像我希望的那样漂亮或在源代码中那样明显。

现在我还没有赞扬什么?Markdown。可怜的 Markdown。别误会我,我喜欢 Markdown。这篇文章就是以 Markdown 格式提交给编辑的。我在学校的讲义是用 Markdown 记的。它非常容易边写边记,并且易于阅读源代码形式。对于简短的独立文档,Markdown 是最好的。

但是编写 Markdown 的容易程度与 Markdown 的最终(缺乏)功能相矛盾。除非您嵌入大量 HTML(那样您还不如不使用 Markdown),否则您将无法获得在长篇材料中变得更重要的许多语义丰富性。选择 Markdown 用于一切事物是很诱人的,因为它降低了贡献的门槛,但是当选择让开发者或用户(在这种情况下是作者和读者)的生活更轻松时,成功的项目往往会偏向用户。

所以,这就是我的观点。文档语言不是一刀切的,因此为正在编写的文档选择合适的语言至关重要。

在评论中告诉我你为什么喜欢你选择的语言。

User profile image.
Ben Cotton 受过气象学家的培训,但天气是一个很棒的爱好。Ben 在 Red Hat 担任 Fedora 项目经理。他是《开源项目项目管理》一书的作者。在 Twitter (@FunnelFiasco) 或 FunnelFiasco.com 上找到他。

12 条评论

我不喜欢 Markdown,因为它有歧义。任何难以解析的标记都难以理解。

我很好奇您认为 Markdown 语法与其他标记语言相比有哪些歧义之处。仅仅是因为 `**` 不如 `<b>` 表达力强吗?

回复 作者:Shawn H Corey (未验证)

我必须看看这里的不同建议。大约一年前,我将工作和其他方面的所有笔记都切换到了 Markdown。然后我在项目或年底使用 pandoc 将其转换为 PDF。对于更长的内容,我使用 LaTeX。当我将我在工作中的所有笔记(包括图片)从 OneNote 转移到 Markdown 时,我从 800+ MB 减少到不到 800 KB。

当我在研究生院时,我所有的笔记都是用 Markdown 写的。在每个单元结束时,我会将笔记渲染为 HTML,打印出来(是的,就像“死树”那样),并用它来学习。除了我的论文数据外,我整个研究生生活都装进了几十兆字节。

回复 作者:jimmysjolund

完全同意:“文档语言不是一刀切的,因此为正在编写的文档选择合适的语言至关重要。” 标记语言就像任何工具一样。您可以将一种语言硬塞到一项它不太适合的任务中,但这很像试图用螺丝刀钉钉子。您或许可以做到,但需要付出很多努力和咒骂。结果也可能很难看。

由于我在 Word Perfect 的“显示代码”功能上磨练了我的文档编辑技巧,我发现直接使用语义 HTML 往往对我来说效果最好。我用文本编辑器用 HTML 写了所有的大学论文,现在仍然用原始 HTML 完成所有文档。好处包括向后兼容性(我仍然可以毫无问题地查看/打印我 90 年代后期的论文)、无需任何工具即可转换为 HTML、相当容易的语义,以及用于列表、侧边栏、标题、表格等的广泛内置标记。每种其他标记语言(好吧,也许除了 DocBook)都会让我在想做一些超出基本操作的事情时,不得不查阅文档以检查语法。

我遇到的唯一棘手的部分是做脚注/尾注,但我拼凑了一个小 JavaScript,将内联脚注 span 元素转换为尾注(脚注更复杂,因为它们需要打印样式表)。

这是供您自己使用,还是您也将其用于协作项目?如果您以这种方式协作,效果如何?

回复 作者:Tim Chase (未验证)

我觉得 markdown 很棒,直到您开始想要覆盖布局。我认为在使用 markdown 时存在一种不成文的协议:您承诺不考虑最终的格式和布局。如果您违背该协议,那么您将承受使用 markdown 的后果。

这或多或少是我对大多数预制解决方案的看法;为了方便,您牺牲了灵活性。这不是一件坏事,只是在采用之前需要注意的事情。

我认为我写下的每一个想法,如果涉及超过三行文本,都不可避免地会经历一个用 Markdown 编写的时期,或者至少,我会给它一个 # 标题和一些 * 项目符号。我还倾向于为我写的东西添加 *各种* 形式的 _强调_,无论它是否会被渲染成任何东西。如果它足够长,以至于我认为它变成了一些不仅仅是给自己看的笔记或电子邮件的东西,并且变成了我可能会发布的东西,我几乎总是会在完成一半之前最终转换为 HTML。不同的人以不同的方式经历他们的创作过程(可能与拖延症不同);对于我发布的东西,我的方式总是涉及在文本完全写完之前就摆弄渲染输出。

我同意你的看法。即使我为了记录正在发生的事情而做的非正式笔记,以便我稍后可以进行实际的撰写,如果不是有效的 Markdown,也几乎接近了。我注意到,即使是我手写的笔记,现在也明显带有 Markdown 的风格。

回复 作者:Jason B

Markdown:小小的标记语言,潜力无限。 ;-D

我已经成为它的一个分支 multi-markdown 的忠实粉丝。额外的语法仍然足够简单,可以直接编写而无需担心它的外观,产生的输出本身看起来相当不错,并且可以在最终输出为 HTML、EPUB、PDF 或任何其他格式之前通过任意数量的工具轻松调整。非常适合编写那些长文档,而不会让您陷入学习另一种标记语言的困境。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.