多年前，我曾寫過一個 Markdown 編輯器，不過是一時心血來潮，沒有認真打理，亦未作宣傳，不覺間竟成了我 GitHub 上星數最多的一個項目。而我認真寫作的一個 Python Markdown Parser 還未過千星，人心之難測幾何哉。 寫 Markdown Editor 不過是因為好玩，過後自己並不曾使用，便至於荒疏了，因為「自己使用是一個很重要的原則」。 選擇 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 編輯器。事實上任何一個大小適合的