使用 Emacs 與 gah 套件實現可塑性運算 (Malleable Computing)

可塑性運算：賦予使用者自主權

可塑性運算是一種新的範式，軟體生產者提供的是構建模組而非僵化的成品，讓使用者能夠調整並重塑其數位工具，以符合其特定的工作流程。與供應商提供的軟體不同——後者為廣大受眾定義功能集——可塑性軟體允許消費者承擔產品定義的責任，透過重新組合現有的函式庫與程式，來創造所需的特定行為子集。

這種方法將開發重心從「為大眾 (N) 構建」轉向「為單一使用者 (1) 構建」。透過為單一使用者構建，開發者可以跳過廣泛錯誤處理、重用模組化以及正式發佈等繁瑣流程，迅速達到「足夠好用」的狀態。

個案研究：用於 GitHub 整合的 gah 套件

gah 套件是 Emacs 中可塑性運算的具體實現。它的創建是為了解决一個特定的摩擦點：手動將 GitHub issues 複製到 Org-mode 以便在 Org Agenda 中進行追蹤。

核心需求

為了避免使用功能完備的 GitHub 客戶端或複雜同步邏輯所帶來的開銷，gah 的設計目標如下：

無縫整合：將 GitHub issues（標題、描述、元數據）作為 Org 任務複製。
減少情境切換：在 Emacs 內完成大部分操作，而非在網頁瀏覽器中。
Org 語法支援：使用 Org 語法表達想法與筆記。
基礎 GitHub Actions：創建新 issue 並在網頁瀏覽器中開啟現有 issue。
零認證開銷：將身份驗證委派給現有的系統工具。

技術規格

gah 利用 GitHub CLI (gh) 作為 REST 服務，將其視為與 GitHub 互動的主要介面。這種架構讓 Emacs 無需直接管理身份驗證。該工具集包含幾個專業組件：

使用者介面：使用 Transient 套件處理選單，使用 Variable Pitch Table (vtable) 進行數據顯示。
轉換：採用 ox-gfm 進行 Org 到 Markdown 的轉換，並使用 Pandoc 進行 Markdown 到 Org 的轉換。
數據處理：使用原生的 Elisp JSON 支援，將來自 gh CLI 的回應反序列化為 Elisp hash tables。

實作效率

其實作非常精簡，僅包含約 392 行程式碼。效率的一個關鍵範例是 gah-request-issues 函數，它透過結合指令列表、用於調度的 shell-command-to-string 以及用於反序列化的 json-parse-string，在不到 20 行程式碼內就完成了 issue 的檢索。

Emacs 的開發優勢

Emacs 作為一個動態程式設計環境，促進了可塑性運算的實現。由於 Elisp 是一種動態語言，且已載入的程式碼之間沒有隔離，使用者可以在運行中的會話中進行原型設計、求值並編排行為，而無需重啟應用程式。

開發者可以使用各種介面進行迭代，包括：

Scratch buffers 與 Elisp 檔案
Org source blocks
IELM REPL、Eshell 或 eval-expression (M-:)

社群觀點與反對意見

雖然 gah 專案突顯了個人賦能的力量，但社群也注意到這種方法的一些細微差別：

現有的替代方案：部分使用者指出，對於類似的 GitHub 整合，已經存在如 Magit Forge 等強大的解決方案。
「粗糙感」因素：可塑性運算的靈活性通常伴隨著一定程度的「vibeslop jank」，即工具對創作者來說功能完備，但缺乏專業軟體的精緻度。
技能差距：可塑性軟體需要一定程度的程式設計技能，這對非技術使用者來說可能是一個障礙，對他們而言「可塑性」可能被視為「複雜」。
同步挑戰：一些批評者認為，缺乏本地/遠端同步功能的工具在專業環境中的效用有限。

「我們工程師習慣於使用的工具是靈活的。只有當我們需要工具能被其他受眾接受時，它們才會變得更加受限。」

最終，gah 套件證明了一個概念：只要有適當的預期與高層次的抽象，使用者可以在一天內構建出高度特定且具備功能的工具——這在封閉、非可塑性的應用程式生態系統中是無法實現的。

使用 Emacs 與 gah 套件實現可塑性運算