纯粹的 Markdown

Markdown 规范和扩展

Markdown 正是因为其简约和通用性才得以流行,通过 GFM/CommonMark 规范进行标准化以后 ,几乎宣称支持 Markdown 的平台和软件都已经做了实现。

目前来说,这是公认“纯粹”的 Markdown,没有那么多“花里胡哨”的东西。用户可以放心使用,通用性和迁移性能够在最大程度上得到保证。

但 GFM 规范不能满足一些“现代化”的使用需求,所以很多软件引入了一些扩展语法(比如上标下标、脚注、公式、图表等),这些扩展语法虽然不一定能在其他平台和软件上通用,但能够满足用户在该平台和软件上的特定需求,然后通过导出功能提供更广泛的格式支持。

前进还是倒退

在扩展语法的道路上越走越远以后,我们发现这似乎是在开历史的倒车。随着更多特定语法的引入,Markdown 的通用性逐步散失,就好像变成了特定软件的私有格式一般。更讽刺的是,语法引入却不能解决 Markdown 最大的问题 —— 自带资源文件(虽然 TextBundle/TextPack 做了一些努力,但就目前而言基本也还是不通用)。

越强大的功能,意味着越复杂的语法,如果沿着这条路一路走下去,语法的复杂度可能会超过人类的可读能力,这将彻底失去 Markdown 的意义。

对于开发者来说,另一条路是一开始就不选择以 Markdown 文本作为存储格式,而是使用更结构化的存储方式,比如数据库或者 JSON,然后在应用层面支持 Markdown 语法排版。选择这条路的开发者,也许已经预见到了将来可能的复杂场景。

用户视角

只有两种语言:一种被人抱怨,而另一种没人使用。

Markdown 显然是前者。

广告 我要投放

12 回帖

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • huangyw 1
    支持者 订阅者

    矛盾需求下的拓荒者

  • abbj 1 3 赞同
    支持者 订阅者

    markdown 的高可读性,其代价是牺牲了功能或者特性的完整性和可扩展性。用户可以任性的提出需求,他们总是希望能有更丰富更强大的功能,同时还希望尽可能的自由(高度的可迁移性,不被某个平台绑定)。

    实际上,由于各平台总有自己独特的功能,功能的完备必然意味着迁移性降低,用户不能要求当前平台的独有特性导出标准 markdown 后能无损迁移到新平台。因此,个人认为,开发者在不断完善功能的前提下,提供尽可能完善的标准 markdown 导出导入支持(如思源笔记目前做的),已经是现实情境下所能做到的最好选择了。

    所以,在支持导入导出标准 markdown 的前提下,建议开发者避免因有意无意的标准 markdown“洁癖”而影响程序的整体设计,不要让程序的功能或性能被“markdown 情结”拖了后腿,只要能增强整体体验,就大胆的“开倒车”。

    感谢 D V 两位兼具情怀、实力和毅力的开发者。

  • rocklaw 1 1 赞同
    支持者 订阅者

    相当于要求用土豆丝做出满汉全席来,这不是强人所难嘛,肯定要加菜啊。请 D 大 V 姐放心大胆地加 😄

  • zengchen 1 1 赞同
    订阅者

    我觉得 纯粹的 md 在现代并不是一个好的笔记格式, 就像楼主你说的, 没有扩展语法, 各种资源也不好统合.

    我之前是用 三维软件的, 像文件格式, 从 obj, 发展到 abc, 再一步步发展到现在乃至未来的通用场景格式 usd.
    本来就是越来越复杂, 但同时也越来越方便人员操作, 因为 usd 把三维制作里所有东西都包裹在一起, 并进行分层, 不再需要操作人员在各个模块来回切换, 而只要一个 usd 就表示一整个三维场景, usd 格式也不再仅限于一个 点线面 (类似 obj 的) 文件 .

    这就好比笔记格式从 单纯的 md 格式 进化成一个 支持 md 语法并可以浏览, 修改并打包 公式, 流程图, pdf, execl 等的一个玩意.

    就像楼主你说的 :

    对于开发者来说,另一条路是一开始就不选择以 Markdown 文本作为存储格式,而是使用更结构化的存储方式,比如数据库或者 JSON,然后在应用层面支持 Markdown 语法排版。选择这条路的开发者,也许已经预见到了将来可能的复杂场景。

    我觉得这是一个发展方向, 我个人也认为原始纯粹的 md 本身并不适合做笔记.
    这并不像更简单 json 取代复杂的 xml 那样, 因为用途不一样, 我觉得 用 usd 做类比, 展望笔记的未来才更合适.

    但可惜的是, 在现在笔记市场上, 并没有哪家公司有这么重的话语权和能力, 能像皮克斯之于三维制作, 开发出 usd, 并进行开源和推广.

    1 回复
  • zjp 1 赞同
    支持者 订阅者

    md 本来就不是为了复杂的记录而生的。。。何必赋予它什么职责或者指责呢?

    1 回复
  • zengchen
    订阅者

    你好像是回复我的?

    我说的是 "单纯的 md 不适合作为笔记格式".

    我本来就没对 md 本身有多少要求, 我需求的是一个更通用更现代更完善的笔记格式.

  • xuanlemming
    支持者 订阅者

    其实纯粹与否并不重要,用户需要的只是好用和功能强大。或者说,在功能强大的基础上,尽可能地保留 md 标准化地输出(分享和迁移),要是能完美导出为 word,感觉也没必要保留 md 格式输出了,因为这算是通用的格式了。我倒是并不觉得 md 多简洁和易用,如果只是好用的 md 工具(替代品实在是过于丰富),那么永远脱离不出 md 的设计框架,那又谈什么进步?更自信一点,真的有很好的设计,其实是会带动它本身的流行的,就像这波双链。

  • devcui
    捐赠者

    万变不离其宗,用户用起来觉得好用顺手,自己要的功能都有便可

  • Morales 1 1 赞同
    支持者 订阅者

    我支持标准化、“纯粹“的 Markdown,但是我认为它不适合用于做任何复杂的工作,只适用于 README、changelog、备忘录、实时聊天 等对格式和排版要求不高的简单场景。

    但即使 Markdown 因为语法的肆意扩展而丧失了通用性,哪怕改的面目全非,我们也不需要担心跨工具的兼容性问题。因为不论“纯粹”与否,Markdown 只是书写用的格式。我们只需要保证结构化存储后的格式的通用性即可,比如用 Docbook。

  • douniwan
    捐赠者 支持者 订阅者

    以后的帮助里是不是就没有这段了?

    1 回复
  • 88250
    订阅者 作者

    是的,之前帮助文档中的碎言碎语章节已经都在社区中发布了,主要是我个人的一些想法,放在帮助里不太适合,可能会浪费用户时间。

  • youth54 1 1 赞同

    正在试用思源 1.2.0,使用 json 格式也很有潜力

请输入回帖内容 ...