[翻译]Orgdown —— 文本文档全新轻量级标记标准

就像创建每一个新标准那样,在启动这种事情之前,你需要非常谨慎地思考。

How Standards Proliferate
Figure 1. xkcd 漫画 “Standards” (Creative Commons Attribution-NonCommercial 2.5 License; https://xkcd.com/927)

因此,我准备在这里解释我提出这个新标准的动机。

你可以观看一段更精简的版本: 我在 EmacsConf21 上的十二分钟视频

问题:一个术语指代两个不同的东西

不幸的是,术语 “Org-mode” 被用来指代两件不同的东西。一方面,它指的是一个基于 Elisp 的软件扩展实现,运行在 GNU/Emacs 平台上。另一方面,它也指一种 轻量级标记语言,类似于 MarkdownAsciiDocWikitextreStructuredText

这两者我都喜欢。

我已经在 GNU/Emacs 上使用 Org-mode 的实现十年了,并且我在本站写过关于我的 PIM 工作流的文章。熟悉的读者也许知道我的链接:https://Karl-Voit.at/2019/09/25/using-orgmode[“Using Org-mode Features (UOMF)”] 系列,在那里我尝试弥合 Org-mode 作为工具与其在日常用户工作流应用之间的鸿沟。

与此无关,我也喜欢 Org-mode 标记的设计。这就是为什么我在 2017 年写了 《Org Mode 是最合理的文本标记语言之一》。让我惊讶的是,那篇文章获得了大量关注,自发表以来在访问量上一直位于我博客文章前十之列。

然而,在那篇文章之后的讨论中出现了很多误解。许多在线讨论里,人们似乎无法区分 Elisp 代码实现与标记语言的设计。我试图表达的观点是:Org-mode 在 GNU/Emacs 之外依然非常有意义。在邮件中、在任何基于文本的个人笔记中、作为论坛或源码仓库的标记、以及所有非 Emacs 中心的工作流里。

问题:缺少对 GNU/Emacs 之外 Org-mode 使用情况的公开展示

在我已经指出了为什么我认为 Org-mode 优于其它轻量级标记语言的主要理由之后,我必须继续处理“实现与标记混淆”的问题。我的意图并不只针对 GNU/Emacs 的用户。我真心相信,即便是永远不会打开 GNU/Emacs 的人,也应该考虑采用 Org-mode 作为文本的标记语言。

当然,当某人从标记新手进阶为希望让自己生活更顺畅的用户时, 用于编写 Org-mode 文本的工具支持 就是强烈推荐的。所谓“工具支持”,我指的是诸如折叠与展开(大纲)、 语法高亮、用于快速插入新元素(如标题)的(键盘)命令、跳转到(内部)链接目标的支持,等等。

在此我想强调:已经有许多工具提供 Org-mode 语法支持。并不是 “GNU/Emacs 或一无所有”。你已经拥有选择。

问题:Org-mode 支持的不同层次

讨论中的一个问题是:GNU/Emacs 的用户倾向于嘲讽其它工具的用户,因为在我看来,GNU/Emacs 中的 Org-mode 在功能与可用性方面一直领先,并且可能还会继续领先。

从我的观点,工具支持对高级用户是必须的,但它——并且应该——完全是可选项。

人们往往假设任何支持部分 Org-mode 语法的工具都需要尽可能接近 GNU/Emacs 中的 Org-mode 实现。在我看来,对多数使用场景来说并不必要。

当你比较例如不同风味的 Markdown 与 Org-mode,你会注意到 Markdown 有着非常有限的语法。尽管 Markdown 缺少许多实用的 Org-mode 元素,它似乎仍然——远远地——是轻量级标记语言中在工具支持和流行度上的主导者。

从这个角度看,普通用户并不需要那些在其它语言(如 Markdown)中缺失的大多数 Org-mode 元素。对于撰写简单文本文档,你并不需要大多数高级元素。

不幸的是,没有一个 Org-mode 的“子集”去反映某种语法支持的里程碑。

Orgdown

为了解决上述所有问题,我认为需要引入一个新术语指代语法。它比 Org-mode 少,但对大多数普通用户的使用场景已经“足够好”。一个新标准,让工具与用户可以比较工具的特性。

因此,我提出名称 Orgdown

它可以缩写为 OD,或者酷一点写成 O↓,甚至是 ⧬。

Orgdown 等级(Levels)

既然我们有了名字,就需要定义 Orgdown 代表什么。Orgdown 只是用来指代 Org-mode 语法(而非任何实现)的名称。

仅有这一点,我们收获并不多。因此,我定义了 以不同等级表达 Orgdown

第一个等级称为 Orgdown1(或 OD1 / O↓1 / ⧬1)。它由一个明确定义的 Org-mode 语法元素子集组成:

  • 简单文本格式

  • 标题

  • 列表与复选框

  • example、quote 与 src 代码块

  • 注释

  • Web 链接

  • 表格(不含计算)

你当然可以讨论在这个初始 Orgdown 等级中包含哪些 Org-mode 语法元素。我尝试寻找一个适合大多数人的折中方案,从基于 Org-mode 的轻量级标记开始。

如果 Orgdown1 不够,我们会用 Orgdown2、Orgdown3 等定义扩展的 Org-mode 语法元素集合。等级越高,支持的元素越多。每个等级支持所有先前等级的语法并增加新元素。

OD1 兼容性指数(Compatibility Index)

这种等级定义的好处在于你现在可以 比较工具支持 了。Orgdown1 可以用 43 个具体特性来概括。每个特性可以以最基础方式(1 分)或高级方式(2 分)被支持。基础支持很容易:不要被这个语法元素搞糊涂。高级支持的定义范围从简单的语法高亮到具备创建或修改该元素的功能。

如果你手头有一个具体工具,你可以测试这 43 个特性,导出每个特性的两种支持级别,累加得到一个最高 86(43×2)的结果。通过相对于该最大可能值计算百分比,你得到一个易于理解的 Orgdown1 支持百分比——OD1 兼容性指数。你可以查看类似 Orgzly 的工具支持页面 来确定一个工具的 OD1 兼容性指数。

由于 Orgdown 托管在 GitLab.com 上,你可以提交文档改进、额外的 OD1 兼容性指数评估以及其它工具的支持页面。

目前的优势总结

我想为所有人总结 Orgdown 的优势:

  • 改善非 Emacs 工具中的 Org-mode 支持

  • 将精心设计的 Org 语法推广给更广泛的人群

  • 促进 Emacs 与非 Emacs 用户之间基于文本文档的协作支持

  • 可比较不同工具的 Orgdown 支持度

  • 最终:修复标记语言语法与 Org-mode Elisp 实现混淆的问题

现在应该做什么?

如果你对 Orgdown 感兴趣,你现在可以: 访问 GitLab 页面按循序渐进方式学习如何书写 Orgdown, 查看 Orgdown1 的语法示例, 在 FAQ 部分 查找更多答案, 浏览 已经支持 Orgdown1 的工具, 并且也许 学习如何为 Orgdown 的理念与标准做出贡献

我需要你的帮助使它成为一个成功案例!

推广这个想法,添加工具,编写更多解析器或改进现有解析器,使用 Orgdown1 这一术语来标注工具特性,通过推广 Orgdown 这一与 Org-mode 及其 Elisp 实现混用区别开的独立术语来扩散理念。

如果 Orgdown 真正引起你的共鸣,你可以向该 GitLab 项目添加一个正式规范。我猜测一些现有的 Org-mode 正式定义在删减到 Orgdown1 集合后已经符合要求。

你可以为 Orgdown1 创建一个 语言服务器协议(LSP),这将极大促进 Orgdown1 在各种编辑器中的适配可能性。

我确实觉得:Orgdown1 是 Gemini 项目 的完美标记候选。这将是一张由纯 Orgdown1 文件构成的链接网络,形成一个没有广告、没有恶意软件、没有臃肿网页的平行互联网,只关注以简单文本文件和链接形式呈现的核心信息价值。虽然这远远超出 Orgdown 的基本想法,但我希望有一天能看到它发生。

与此同时,让我们用 Orgdown1 来启动 Orgdown,并通过 Orgdown 这一明确定义的标准传播 Org-mode 的优秀标记设计。

原文发布于 2021-11-27T16:56