不得不说的一些问题

你真的知道 Markdown 的原作者是谁吗？

Markdown 的原作者只有一个，叫 John Gruber。

但很多人以为 Aaron Swartz (具体了解请观看《互联网之子》)也是共同作者之一，这是谬传。

下面这个是 John Gruber 的原话:

Probably referring to Aaron Swartz, whom Wikipedia incorrectly credited as co-creator for years.

I should write about it, but it’s painful. More or less: Aaron was my sounding board, my muse.

至于为什么 Markdown+Aaron，会产生化学作用被谬传这么久，这里面或许也有荒唐的一面: 因为Aaron 很酷，信息变革而献身的悲剧式英雄人物。

当不少人认为 Markdown 也是 Aaron 的遗作之一，Markdown 就有了光环，它相当的酷啊，从而显得认为它很酷的自己也很酷……

John Gruber 发明的 Markdown 跟你用的可能不一样

John Gruber 发明了 Markdown，这个Markdown 既是语法规则，也是一个成品的程序。但这个 Markdown 跟你实际在使用的，应该说不完全是同一个东西。

Markdown 是十多年前发布的，很多语法规则有当时的历史原因造成的，比如为什么原始 Markdown 语法换行需要两个空格、为什么默认使用缩进来处理代码块、为什么本身语法倾向于去除 HTML 的冗余但其自身却有好些冗余的语法 .etc，如果放置在当时的年代，应该就能隐约理解这些设计的缘由。

还有，John Gruber 发布的 Markdown，实际上是用 Perl 写的一个 1000 多行的程序，可以直接命令行调用，主要功能是将 Markdown 文本解析为 HTML。

客观的来说，(最初发布的) Markdown 就是一个很小的程序。或许在很多普通人眼中，都不能算程序，因为没有操作界面呀。

再另外一方面，我们现在实际用到的各种 Markdown 解析库，极其罕见到有谁会选择 John Gruber 提供的这个……

把 Markdown 的意义夸张了吧？

有人说 Markdown 是只做“标记”，不负责样式、排版的。说的当然，没错。但实际上 Markdown 的最终产物 HTML 根据各个标签而有默认样式的，“标记”跟“样式”并不是完全有机割离的。

有些时候，我觉得有些荒谬，因为有人问为什么 Markdown 不能做到首行缩进，就被另外的人开启嘲讽状态。

而实际上呢，这个是 CSS 规则决定的，Markdown 默认使用 P、BR 作为最终 HTML 结构的段落、行， 10多年前的这个选择很自然呀! (其实现在我们也可以完全换一种渲染方案)

P 标签可以实现首行缩进，但是 BR (默认) 不行。可这也是10多年前不行，现在浏览器的 BR 标签也不是不能首行缩进，只是实施起来很吊诡，有浏览器兼容问题，而未来的 CSS 草案中，已经明确表示会支持 BR 的 text-indent 类似的属性……

总之，Markdown+首行缩进，就会被嘲讽，这样的局面我不是太能理解。有时候，我们中的部分朋友，会不会把 Markdown 的 原旨主义 夸张了，从而形成自己不切实际的、作为Markdown使用者的骄傲感？

我所理解的 Markdown 的意义，就是懒、高效、舒服，没有一点是跟逼格相关的。

Markdown 的表现不够？

除了 Markdown 之外，你或许还听过 LaTeX、reStructuredText、Org-Mode、AsciiDoc，或许也看过一些对比的文章。

实际上很多 xx VS xx 的论据是站不住脚的，很难评判谁更好谁更糟，但是 Markdown 的门槛很低，这是毋庸置疑的，所以相比其它标记类语言，Markdown 才被更多的人接受。

而至于 Markdown 什么能做，什么做不了，其实很大程度并不是 Markdown 本身决定的，而是某些具体工具决定的。在我的理解中，Markdown 的存在就像是一种基础协议，至于后面怎么演绎、完成什么的工作，就不管了；这种角色很像 HTML，它只负责基本的结构定义，至于最终的页面好看不好看、变成什么样，并不是它要负责的。

有朋友认为 Markdown 不能进行严肃的写作，LaTeX 可以，Org-Mode 可以。其实不尽然，Markdown 当然能进行严肃的写作，完成一本书、一个 API 说明的文档都是能胜任的。如果说 Markdown 真正技穷的地方，那就是 Markdown 不能进行过于复杂的写作，Markdown 要取代 LaTeX，这个绝无可能；就如 LaTex 变得跟 Markdown 一样容易入门也绝无可能一般。

很重要的一点，或许大家会忽略的: 其实，多数人、多数时间、多数场合，我们书写文本的要求，是并不复杂的。在这个时候，怎么简单怎么来，反正最终效果不会有本质的差别；而此时采用的解决方案，不论是 Markdown 还是 Org-Mode 或者 AsciiDoc，都只是习惯而已。

当然，也可能是我的短见，LaTex 或许也可以变得很简洁，而 Markdown 也可以变得很强大。这种可能性未必是不存在的，只是短期来看，不太现实。

呃，还没有形成自己的书写习惯？ 那还想什么，当然是 Markdown。

Markdown 应该不用学习吧……

Markdown 涉及到的语法是有限的，基本上就不用学习，只要花1-2分钟，了解标题、加粗几个基本语法就足够了。更多的，在使用过程中慢慢了解就够了。

并不需要一次性把它所有的语法都掌握了，没有必要，特别有些第一次接触的朋友，“遗忘”会是一个比较大的敌人，当下语法都记住了，后来又都忘记了。

放弃一些，就会发现 Markdown 的规则实在太简单了，简单到很难忘记。

这种放弃，也延续在 Markdown 的扩展性中，只需要理解它运行的方式，放弃对一些华丽的格式的控制，Markdown 在不断的使用过程中，会带来更多的惊喜。

编辑器们的泛滥？

Markdown 的编辑器，从某种角度来说，确实很多，甚至有段时间犹如雨后春笋一般。又一个 Markdown 编辑器从最初的自我介绍，差点能成为别人口中调侃的理由。

但是如果将这些软件按照作者的开发时间分两类，相信很多会被归档到耗时不多的练手之作类别内。

耗时比较多的 Markdown 相关软件，其实也不算太少，而且免费、付费都已经很好的覆盖到了。

抛开练手之作，个人不会觉得 Markdown 软件有什么泛滥，反倒是一个比较恰当的状态，并不会产生真正的选择困难症。

Markdown的编辑器们

从表现形式来来看: 一种是平文本，这个比较常见; 另外则是可视可见的富文本，也叫WYSIWYG (what you see is what you get) ，这个比较少见，典型的是 Typora。

我个人更喜欢的是平文本模式，而不是 WYSIWYG，很多 Markdown Editor 中，这种模式是被改良过的，一方面是各种标记文字用色彩进行高亮区分，另一方面支持图片拖入、粘贴等方式插入以及直接显示，实际效果来看，是介于“纯平”与WYSIWYG 之间，甚至更倾向于后者。

而纯粹WYSIWYG的模式，实现的基础要借助 HTML 本身的编辑。这很难! 因为 Markdown 转为 HTML 的结果是可预见的，而 HTML 转回 Markdown 是不可完全预见的，并非完全等价转换。

如果要实现一个 WYSIWYG 的 Editor，需要应对的例外情况很多，个别情况下甚至可能无法保证完全对应。

至于 WYSIWYG 是否适合 Markdown 的编辑，这本身是有争议的。

但所谓“争议”其实也没多大意义，重点是能否适合自己的书写习惯。

于我而言，不太喜欢WYSIWYG，因为它会大大降低自己的写作效率；但同样也有朋友很喜欢这种模式，因为他实际上并不太依赖 Markdown的语法，作为 Word 的一个替代品，WYSIWYG 式的 Markdown 编辑器反而是一个很棒的选择。

从管理的表现来看: 一种是纯编辑器不带管理，一种则是自带管理(文件管理器或者 Library 的模式)。

我个人更喜欢的后者。因为对文本处理工作有重度依赖的时候，没有管理功能的 Editor 其实在不少场景下有些着急，会产生不必要的效率浪费。

从“血统”来看: 一种是特定的 Markdown Editor，一种是通用的编辑器，前者的基础格式就是支持 Markdown 的，而后者则需要通过特定的、原生的插件来实现。后者也有很多选择，一般的 IDE、多数的代码编辑器，常见的比如 Atom 都是很不错的。一般性使用，通用的编辑器其实也不错，只是有些时候太过于通用，使用者有更多想法的时候，就有点无法应对了。

很酷的 Markdown

用不起来的 Markdown 一点都不酷

使用 Markdown 很酷？

不会。

很酷的人，用什么都会显得很酷。

问题在于使用者本身……

可能有人告诉你: XX 很贵所以很好；我用过 N 款 Editor，就 XX 是最好的...

可以作为很好的参考意见，但是不要听信。总而言之，花上半天、一天的时间，几个 App 的试用版都尝试下，就能做出自己的选择了。

然后，最最重要的事情来了。就是要把 Markdown 用起来!

什么才算用起来？ 那就是这个写作 App 基本上是处于常驻状态下。

不论是工作、日常记录、写作、文档、Todo .etc, 凡是跟文本相关的工作，Markdown Editor多数时候都是完全能胜任的。不要雪藏自己的利器。

甚至有些朋友花了500买 App，结果基本不用，试图靠多花钱来督促自己多写点东西，这样的动机，一般是不会成功的。

但就是很酷呀

我个人认为不论潜意识还是“明意识”里把 Markdown 等同于 酷，都不是推荐的操作方式。

就只是一个工具而已。

就是拿来用的，而已呀!

但奇怪的事情也发生了。

如果一个团队愿意接受 Markdown、并且用得不错，一般来说，这个团队不会太糟糕。反之，一个从没听说过 Markdown 或者 拒绝Markdown 并且没有更好的解决方案的团队，然后又强调自己的创新能力，这样的团队，就要小心了……

而这个逻辑奇怪的地方，并不在于 Markdown，而是一个很酷的团队，总是不断出于学习的状态，如果一个产品、一个语言、一个工具，它具备更高的效率或者仅仅可以让使用者更偷懒，那么这个团队就会去拥抱它。仅仅是拥抱，还不够，还能用得很好，这样的团队，才会变得又酷又成功。

这就是我的观点:

你比很多人先知道 Markdown，这不错。

你比很多人先投入 Markdown 的使用，这非常不错。

你使用 Markdown，节省了更多的时间，创作更多成果，这就非常酷了!

把 Markdown 换成别的名词，也同样成立。

如何才能让 Markdown 更酷起来？

Markdown 吸引人的地方在于其简洁。

而简洁的事物，到达一定边界的时候，就有概率脱离其本体，产生进化。

我们自己在 Markdown 应用的阶段做了不少尝试。

比如在 Markdown 的文档中直接引入动态的脚本语言:

实际的界面效果:

我们还尝试在 Markdown 之上，增加了一层新的、可自定义的渲染引擎:

比如下面这段文字

// timeline
## Work and Education
Dec 2012 to Now:  Product Leader @Z.R.E.Y Co., LTD.
Nov 2011 to Dec 2012: Chief Architecture @Funny Co., LTD.
Jul 2007 to Nov 2011: UED Leader @BAE
Dec 2003 to Jun 2007: MBA @No.1 School of the Earth

// score
## Technical Experience
Python: 9
Coffee: 7
Lua: 6
Linux: 6

最终效果会变成:

当然也有其它不少的尝试，但一一足道，就显得繁琐了。

最后

Markdown 是一门很老的语言了。

或许未来的十年，它会产生更多的可能。

又或许有新的替代工具出现了。

如果，可以让我们的生活变得更好，就赶紧拥抱。

毕竟，因为你很酷，所以，才显得 Markdown 这类美好的事物也是相当的酷了。