獨行 Emacs 兩年記：35 個模組、零外部套件與全面重構

背景

這篇文章記錄了開發者 Rahul 維護其 Emacs Solo 專案兩年的心得。該專案的核心原則是「零外部套件」，所有功能皆依賴 Emacs 內建工具或自行撰寫的 Elisp 模組，旨在追求配置的極致穩定性與自主掌控權。隨著專案進入兩週年，作者進行了一次大規模重構，將設定拆分為核心配置與 35 個自製模組，引發了 Hacker News 社群對於「極簡主義」與「造輪子」之間權衡的熱烈討論。

社群觀點

社群對於這種「苦行僧式」的配置方式展現出高度的共鳴與敬佩。支持者認為，這種做法解決了現代開發者普遍面臨的「套件依賴地獄」。當開發環境過度依賴外部套件時，一旦上游更新導致中斷，修復配置往往會干擾正常工作。有留言者指出，親手撰寫功能的價值不在於追求完美，而是在於「掌控感」。這種掌控感意味著當工具出錯時，開發者能精確定位問題所在，而非在數千行陌生的原始碼中迷失。這種觀點反映了資深工具使用者對穩定性的渴望，即便自製工具在功能上可能不如主流套件全面，但其帶來的心理安定感與維護便利性往往更具吸引力。

然而，這種極致的自主性也伴隨著代價，社群中不乏對此感到「既羨慕又卻步」的聲音。部分使用者坦言，雖然渴望擺脫對第三方套件的依賴，但現實中的時間成本與自律要求極高，這被形容為一種近乎「受虐癖」的自我挑戰。特別是在企業環境中，開發者可能無法自由選擇工具，或沒有餘裕去重新發明輪子。此外，關於自製工具是否應該開源，社群也出現了有趣的討論。有開發者分享自己撰寫了極為實用的自訂功能，例如能精準擴展選取範圍的函數，但卻因為擔心需要承擔後續的維護責任與滿足各方需求，而選擇不將其公開。這顯示出在個人化工具與通用軟體之間，存在著一道難以跨越的心理與責任門檻。

在技術實踐層面，討論也觸及了內建工具的極限。例如針對 C++ 等複雜語言的開發需求，使用者開始權衡內建的 Eglot 與功能強大的外部套件如 emacs-lsp 之間的優劣。這反映出即便是在追求極簡的社群中，對於特定專業領域的生產力工具，內建方案是否能完全取代成熟的第三方生態系，仍是一個存在爭議且值得探討的議題。整體而言，社群共識傾向於認同這種「回歸原生」的嘗試具有極高的學習價值，但其推廣難度主要在於個人時間資源的分配。

延伸閱讀

在討論中，有使用者提到了一些具體的技術實踐與工具對比，值得進一步探索：

• Eglot：Emacs 內建的 LSP 客戶端，常被拿來與功能較重型的 emacs-lsp 進行效能與配置複雜度的比較。
• Tree-sitter：現代 Emacs 核心逐漸整合的語法解析引擎，是實現高效代碼導航與選取功能的基礎。
• compile_commands.json：在 C++ 開發環境中，如何引導內建工具正確識別專案結構的關鍵配置文件。