多年前，我曾写过一个 Markdown 编辑器，不过是一时心血来潮，没有认真打理，亦未作宣传，不觉间竟成了我 GitHub 上星数最多的一个项目。而我认真写作的一个 Python Markdown Parser 还未过千星，人心之难测几何哉。

写 Markdown Editor 不过是因为好玩，过后自己并不曾使用，便至于荒疏了，因为“自己使用是一个很重要的原则”。

原文繁体字，刊载于我的博客：《談談 Markdown 編輯器》。

选择 Markdown 便是选择自由，选择不受制于编辑器的自由，因为任何一个文本输入框都可以成为你的 Markdown 编辑器。

正如 Markdown 的作者 John Gruber 所言：

A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions...

To this end, Markdown’s syntax is comprised entirely of punctuation characters, which punctuation characters have been carefully chosen so as to look like what they mean. E.g., asterisks around a word actually look like emphasis. Markdown lists look like, well, lists.

虽然 Markdown 整体的语法设计并不完美，但并不妨碍它成为当今最流行的文本标记语言。诚如 John Gruber 所说，Markdown 的标记符号确实是精心挑选的（carefully chosen）的，符号本身的表意简洁明了，而需要学习的语法量较少，最是适合文字工作者。

譬如当我们看到**这种强调**的文法时，我们一眼便知道它表示强调，而不必看到渲染后的结果，这也正是 Markdown 的设计初衷。如果你必定要使用一个 Markdown 编辑器才能使用 Markdown 写作的话，“你可能在用假的 Markdown”。

自然，我并不是排斥 Markdown 编辑器。即使达到了手中无剑心中有剑的境界，亦不妨手持利刃，只是其究竟是否利刃？

最下者，实时预览之 Markdown 编辑器。何也？实时预览一是无用，二是扰人思绪。

编辑器之实时预览多半与最终呈现效果并不一致，最终的展现效果当是由最终页的样式决定的，而这个样式通常并非实时预览时的样式。既是如此，又何必实时预览。Markdown 是所想即所得，假使预览，亦只是检查一下是否有些许不当的标记文法。

更要紧者便是扰人思绪。写作之时，当专注于内容，而非样式。不像一般的所见即所得编辑器，Markdown 的实时预览多半是与写作输入框分开的。实时预览，屏幕便不得不实时刷新，勾引作者去看渲染后的结果，于写作无益，打扰作者思绪罢了。

次下者，花姿招展文法高亮之 Markdown 编辑器也。这不过是代码编辑器的通病，用颜色来提示代码文法固然不错，但用于 Markdown 则失之偏颇了。颜色是用来提醒代码文法的，Markdown 却是写作之用，这番提醒于写作无益，亦只是打扰作者思绪罢了。便是有文法高亮，亦当节制，不过灰度上的变化便可。

我个人觉得 GitHub Issues 的输入框便是很不错的 Markdown 编辑器。事实上任何一个大小适合的 <textarea> 都是个合格的 Markdown 编辑器，如果再加上一个最终预览功能的话，便是锦上添花了。GitHub Issues 的输入框正如此，其预览功能所显示的样式亦是文字最终的呈现效果，最是完美的编辑器。

这样想来，我之所作编辑器倒不算很坏的编辑器，文法高亮之颜色相当节制，有预览功能而无实时预览之扰人。是否应该捡起这最多星之项目呢？可是我已成为了 <textarea> 爱好者，于此种编辑器并无怜惜之情。

最后一点建言。排版，应当是写作完成之后才需要做的事。写作需要无拘无束，心无旁骛。便如图片、链接等，可于写作完成之后再标注，图片不妨在其处放一个标记符号，链接不妨先放在文本框里，不急于与文字对应上。待到文字有成，需要预览之时，再拾遗补缺。