編寫我自己的文字編輯器，並將其作為日常主力工具

背景

這篇文章源於開發者 Josh Barretto 分享他過去兩年自行開發並在日常工作中完全採用自製文字編輯器的經驗。作者因不滿現有編輯器在遠端連線、專案搜尋效能及終端機整合方面的表現，決定從零開始打造一個符合自己直覺的工具，並分享了從「吃自家狗糧」到處理游標邏輯的心路歷程。

社群觀點

在 Hacker News 的討論中，社群對於「自製工具」展現出高度的共鳴與敬意。許多留言者認為，儘管市面上已有無數成熟的編輯器，但開發專屬於自己的工具能帶來無可取代的價值。有讀者指出，這種行為雖然在旁人眼中可能難以理解其價值，但對於創作者而言，這是一種將工作環境打造成「個人城堡」的極致體現。甚至有網友認出作者正是先前完成《超級瑪利歐 64》GBA 移植版的技術高手，因此對其編輯器的品質抱持高度期待。

然而，討論也延伸到了開發層面的現實挑戰。有經驗的開發者提醒，雖然初期使用字串緩衝區（String-backed buffers）開發較快，但若要處理大型檔案，勢必會遇到效能瓶頸，建議可以採用如 Ropey 等成熟的資料結構套件來優化效能。此外，部分讀者對於作者未在文中直接提供原始碼連結感到遺憾，認為這類充滿個人色彩的專案往往能激發更多技術交流。

另一派有趣的討論則聚焦於「編輯器的哲學」。有留言者提出，除了從零開始寫一個完整的編輯器，或許存在一種介於「高度自定義配置」與「完全自製」之間的中間地帶。他們渴望一種更模組化的架構，能像樂高一樣組合不同的執行檔來處理檔案搜尋、輸入映射與緩衝區顯示，而不是被迫接受一個巨大的單體軟體。這種觀點引發了對經典系統如 Acme 的討論，後者透過簡約的 API 與外部系統整合，而非追求無止盡的內建功能。

最後，社群中也不乏懷舊的聲音。有開發者回憶起 90 年代為了避開簡陋的系統內建編輯器而自製工具的往事，感嘆當時在硬體效能極其有限的情況下，自製工具的反應速度反而比現代的 VS Code 還要流暢。這種對「速度感」與「掌控感」的追求，正是驅使工程師不斷投入時間開發個人工具的核心動力。

延伸閱讀

在討論過程中，社群成員提到了幾個值得參考的資源與工具。首先是 Acme 編輯器，它代表了一種與現代編輯器截然不同的設計哲學，特別是其視窗操作 API 與透過 Plumber 實現的系統整合機制。對於追求效能的開發者，留言中推薦了 Rust 生態系中的 Ropey 套件，這是一個專門為文字編輯器設計、基於 Rope 結構的緩衝區管理工具。此外，也有人分享了關於 Acme 系統文件的 man page 連結，供對極簡主義編輯器感興趣的讀者深入研究。