何必為區區 Markdown 裝一堆工具？
目前 Markdown 仍然是寫給 AI agent 最常用的文件格式，在每個用到了 AI 的軟體專案下，大概都會看到一個 AGENT.md 檔案。
痛點
為了編輯這種最簡單的純文字檔案，卻可能得在電腦上面裝上好幾 GB 的各種軟體。
Markdown 是一種任何文字編輯器都可以開啟的檔案，什麼最原始的 Windows 記事本都可以開啟（現在 Windows 的記事本甚至直接內建 Markdown 預覽功能），在大約二十年前 Markdown 發明之初，就是為了讓純文字也有一些標題、列表、連結語意，不用這些而需要額外的文書軟體。
不過，身為軟體開發人員，為了工作、為了寫程式，總還是要裝上幾套編輯器與 IDE，有些人裝 vim 還是 Emacs，為了特定領域的開發，又要裝上 Visual Studio Code 啦、Xcode 啦、Android Studio 以至於 JetBrains 的 IntelliJ 啦，每一套 IDE 都可以打開 Markdown。拿笨重的 IDE 處理 Markdown 又很礙事（macOS 上預設拿 Xcode 開啟 Markdown 也是一絕），有天你發現你的 VS Code 因為裝了太多 extension 也很笨重，所以想試試看 Zed，裝了 Zed 之後，又發現自己離不開 VS Code，所以 VS Code 與 Zed 全都裝了。
接著，你可能聽說 AI Agent 並沒有你想得那麼聰明，AI Agent 並沒有你所在領域的知識，所以在原本的編輯器與 IDE 之外，又另外裝了一套個人知識庫軟體，可以幫你將分散的 Markdown 檔案打 tag、加連結，之間建立關聯，從而打造知識網路。裝了一套之後（可能還加裝了一堆 plugin/extension），還沒真的把什麼知識網路建立起來，覺得不好用，所以又換了一套，但原本那套已經建立了一些檔案，又可能捨不得刪，所以那套還是繼續留著。
文字圖表
另一件麻煩事，則是 Markdown 裡頭還可能包含圖表。以我比較熟悉的 app 開發來說，這幾年的 app 大概都走向的宣告式 UI 以及狀態驅動開發，在描述一個 app 的行為時，與其在 Markdown 裡頭加上一大堆的文字描述，還不如用 PlantUML 或 Mermaid 語法表達一張 State diagram。但許多時候，標準的 UML 可能無法表達軟體的流程與架構，因此人們又（產生文件的 AI Agent 也會）在 Markdown 檔案中，插入一些把純文字當圖形用的文字流程圖，英文大概叫做 ASCII/text diagram。
各種編輯器、IDE 還是什麼個人知識系統，又普遍缺少編輯文字圖表的能力，在原本的編輯行為中，如果想要調整某條線框的位置，大概就是要按一堆空白鍵。所以又誕生了一批專門用來編輯文字圖表的工具，像是網頁版本的 asciiflow.com、textik.com，或是桌面軟體 Monodraw。這些工具解決了一些問題，但同時也造成新的問題。
這些文字圖表工具通常提供的是某種單向的流程：當你把工具產生出來的內容，貼到原本的 Markdown 編輯器之後，沒辦法再把這些文字再貼回 asciiflow 等工具編輯。這些工具大概的原理是 — 編輯過程中，並不是操作文字，而是操作一系列描述形狀、線段的物件模型，然後由這些物件匯出成文字，文字貼到 Markdown 裡頭，那些物件（姑且稱為原圖），還是停在另外一個工具裡。
因此，如果想要修改某張圖，就沒辦法直接在 Markdown 裡頭改，而是要回去找一開始的原圖，這些原圖通常不會跟著 Markdown 一起交付或是進入 git repo，Markdown 與原圖之間也沒有什麼建立關聯的方法，讓人難以找到原圖。想要修改這張圖，大概又得在編輯器裡頭按一堆空白鍵。
這些工具還有一個更致命的問題 — 這些工具是在英語等西方語系地區開發，都假設一個字、一個線段都只佔一個視覺單位，只要想在上面放中日韓等亞洲語言，畫出來的圖都會跑版。
最後，編輯區區一個 Markdown 文字檔，卻變成一個散亂各地的流程 — 現在許多 AI Agent 的工作，是在終端機下的 CLI 環境進行，要讓 AI Agent 做事，不見得要在自己的電腦上執行，大可以放一台遠端主機，然後用 ssh 連線進去與 AI Agent 對話，可是，你可能要開一個 GUI 編輯器還是個人知識系統 — 在一百次使用 Markdown 的場合，會用到 Markdown 之間的連結的場合可能不到半次 — 然後再開另外一個網頁或是專屬 GUI app 處理文字圖表，原本在鍵盤中的工作流程被打斷，要切換到用滑鼠拉框。
我真的覺得，寫 Markdown 可以是更簡單的事。
我做了一個工具，想讓這件事變簡單 — 有人看到這裡，大概會覺得「啊，還不是多了一個工具」，話是沒錯，但我這套工具帶來的系統負擔，應該遠小於上面提到的那些，只有 5MB 不到的大小。
我想要的是這樣的東西：
- 一套輕巧的命令列 TUI 編輯器，可以讓我在遠端編輯文件，也可以跟 AI Agent 一起活在 tmux 裡頭。除了 Markdown 之外，還可以用來編輯一些常見的文字檔案格式
- 一套 2D 文字畫布式的編輯模式，讓我就算只有 Markdown 裡頭的文字圖表，我也可以輕鬆修改，而不會把圖表搞壞
- 一套簡單的繪圖命令，例如，打一個 BOX 就可以畫框，打一個 LINE 命令，就可以幫兩個框之間拉好線
還有：正確處理中日韓字元
這個專案叫做 zago，取自於「zonble 的 nano 與 LOGO」，其實也結合了一些過去 PE2 的行為。
https://github.com/zonble/zago
來自 nano 的基礎文字編輯行為
幾個星期前我 fork 了一份微軟的 edit，是微軟這幾年用 Rust 重寫的終端機編輯器，復刻了 DOS 下的 edit 命令的行為。那時候我改得十分開心，讓 AI Agent 幫我把一堆稀奇古怪的行為放上去。玩著玩著，發現微軟 edit 還是做不到我想做的事 — 在既有架構下，好像塞不進前面所說的畫布模式與繪圖命令，不如起新爐灶。
微軟 edit 對我來說也有個問題：他其實是為了 Windows 設計的，他的按鍵對應 — 所謂的 key binding — 在其他平台上不見得能用，我雖然偶而會用 Windows，但工作還是以 macOS 與 Linux 為主。我應該還是以一套 macOS/*nix 行之有年的編輯器行為為基礎，而且按鍵簡單就好，我要的是一個單純的寫作環境，不是什麼強大的 IDE。
於是很自然地選擇了 nano — 用 Ctrl+X 離開，Ctrl+O 存檔，就是這些簡單的操作。
我也加了一些符合個人寫作習慣的行為，像是我習慣在一行 30 個中文字的環境下寫作，所以加上了自訂的換行寬度；我也經常會注意一段當中到底寫了多少字，所以在編輯器右方，還會額外顯示這一段佔了多少視覺行，以及裡頭的字數統計。
來自 PE2 的 2D 文字畫布
有時候我懷疑，之所以會有那麼多 web based 或是專屬的文字圖表編輯工具，可能是因為現在主流編輯器普遍沒有把文字當成畫布的想法，但台灣人則不一樣，把文字當畫布可能是台灣人被訓練過的肌肉記憶，因為台灣曾經經歷過一段有趣的 PE2 時代。
在 90 年代，整個世界的文書編輯的主流，是 DOS 版本的 WordPerferct、WordStar 等，不過這兩者在台灣都沒流行過，原因是與 DOS 下的中文環境 — 無論是倚天、國喬… — 不相容。
WordPerfect 自己就是一個記憶體怪獸，跑了 WordPerfect 之後，什麼別的都不用跑了；WordStar 則是在字元編碼上做了奇怪的事，每個 ASCII 碼只用了 8 個 bit 中的 7 個 bit，WordStar 為了某種西方視角的效能考量，就把最後一個 bit 拿去當成一些排版指令，遇到 Big5 等中文編碼方式，就會直接把中文存成亂碼。放眼望去，DOS 下能跟中文編碼和平相處的，大概就是 IBM PE2，PE2 就是一套將編輯區當做畫布的軟體。至於 PC/DOS 以外的系統，大家買不起。而等到大家習慣那種會自動換行、一維文字流式的編輯環境，已經是微軟挾著 Windows 鋪天蓋地的威力，用 Word 成為文書市場之霸以後的事，而 PE2 式的編輯也慢慢淡出市場。
台灣人在 90 年代搞出許多 PE2 魔改版本。在 PE2 中，可以將輸入游標移動到任何位置，如果一行字只有 20 個字，在現在的編輯器中，游標就只能夠停在第 20 個字的位置，但 PE2 卻讓你可以一直移動到更後面的地方，四面八方隨意移動，在畫面中選取內容時，也不是選取那行的哪個字到哪個字，而是選出一個正方形的區塊（block）。
Get zonble’s stories in your inbox
Join Medium for free to get updates from this writer.
台灣的 PE2 魔改版中，就把四面八方移動的方向鍵拿來畫線條，拿區塊來畫框。台灣人拿這些框線建立公文、建立商業文書，甚至是文字 BBS 的歡迎畫面。而其實，現在出現在 Markdown 當中的文字圖表，跟當時的應用並沒有多少差異。
zago 可以切換到畫布模式，或許可以說是在找回這些三十年前的手感。在畫布模式下，按 Shift+方向鍵用來畫框，用 Ctrl+Shift+方向鍵畫箭頭，然後用 Ctrl+^ 建立選擇區塊。
把古老的小烏龜畫圖塞入編輯器中
zago 裡頭有一套繪圖命令。這套繪圖命令其實是一套完整的程式語言，在 zago 裡頭可以寫程式，但真的操作起來，一點都不像是寫程式，至少我小學四年級接觸這門語言的時候，我根本不知道我在寫程式。
如果要畫一個這樣的圖：
┌──────┐ ┌────────┐
│ User ├──────→│ 資料庫 │
└──────┘ └────────┘在 zago 裡頭，首先按一下 ESC，然後輸入
BOX UserBOX 這個字的大小寫沒差，也可以打成小寫的 box。就會產生
┌──────┐
│ User │
└──────┘接著，可以在將游標移動到 User 旁邊的框，輸入幾個空白，或是用畫布模式隨意移動游標，然後打
BOX 資料庫就會產生
┌──────┐ ┌────────┐
│ User │ │ 資料庫 │
└──────┘ └────────┘最後，移動到 User 框的旁邊，打一行
LINE就可以在兩個框之間建立連線
┌──────┐ ┌────────┐
│ User ├───────┤ 資料庫 │
└──────┘ └────────┘LINE 後面可以接
- LINE SINGLE ; 單線框
- LINE DOUBLE ; 雙線框
- LINE ASCII ; 雙線框
也可以加上箭頭
- LINE [SINGLE|DOUBLE|ASCII] [ARROW|BACKARROW|BOTHARROW] ; 往右/往左/雙向箭頭
如果只是畫圖，那麼，只需要會 BOX（會把周圍擠開的框）、DRAWBOX（直接覆蓋上去的框）、LINE（水平線）、VLINE（垂直線）就夠了。而這套語法其實可以繼續組合出各種應用，像是畫三個框：
REPEAT 3 [BOX "嗨]就會畫出
┌────┐┌────┐┌────┐
│ 嗨 ││ 嗨 ││ 嗨 │
└────┘└────┘└────┘
zago 裡頭用的這套命令或是語言，叫做 LOGO，以加州大學柏克萊分校的 UCBLogo 為基礎，針對文字編輯器的應用場合而新增與刪除裡頭的一些函數，與原本的 LOGO 不太一樣，我叫他 Editor LOGO。
一些中年人大概小時候在學電腦的時候接觸過 LOGO，可能是在課堂上的 PC 或是 Apple ][ GS 電腦，用 FD、LEFT、RIGHT 這些指令，控制螢幕上一隻烏龜的方位，讓烏龜在移動的時候畫出現線條，還可以用迴圈畫出繽紛的圖形。
這門語言在 1967 年誕生，距今將近六十年前，是一門古老，但我覺得長期被低估的語言，或許是因為小烏龜畫圖太成功，太深植人心，讓人們以為 LOGO 就是一門只用在兒童教育的玩具語言，但 LOGO 語法簡潔、也有很多高階函式特性，可以用來開發應用。至少，在一個想要有好用的文字圖表功能的編輯器裡頭，LOGO 可以幫我把畫圖這件事做好，畢竟這個語言有著畫圖的基因。
zego 可以在 macOS 與 Linux 上使用，不過我還沒有在 Linux 上完整測試。使用 Swift 6 語言開發，可以用 homebrew 安裝。
這篇文章是在 zago 裡頭打的。總要自己天天用，才會知道哪裡有 bug。
