Malleable Computing with Emacs and the gah Package

Malleable Computing with Emacs and the gah Package

Malleable Computing: Rapid Tooling via Emacs

Emacs enables "malleable computing," where users can rapidly adapt and reshape their digital environment by combining a dynamic programming language (Elisp) with existing system utilities. This approach allows developers to build highly specific tools for their own workflows—often in a matter of hours—without needing the full development cycle of a standalone application.

Case Study: The gah Package for GitHub Integration

To solve the friction of manually copying GitHub issues into Org-mode for tracking in an Agenda view, the author developed gah, a lightweight Emacs package. The goal was to minimize context switching between the browser and Emacs while avoiding the complexity of building a full-featured GitHub client.

Core Requirements

  • Seamless Integration: Copy GitHub issues (title, description, metadata) as Org tasks.
  • Workflow Efficiency: Create new GitHub issues and open existing ones in a browser directly from Emacs.
  • Low Overhead: Avoid managing GitHub authentication manually and minimize development time (aiming for a working prototype within a week).

Technical Specification

Instead of writing a complex API client, gah treats the GitHub CLI (gh) as a REST service. This delegates authentication to the CLI and simplifies the data pipeline:

  • Backend: GitHub CLI (gh) for data retrieval and authentication.
  • UI Components: Transient for menus and Variable Pitch Table (vtable) for data display.
  • Translation: ox-gfm for Org-to-Markdown and Pandoc for Markdown-to-Org conversion.
  • Data Handling: Native Elisp JSON support for deserializing gh responses into hash tables.

Implementation Example

Retrieving issues is handled by a concise function that constructs a shell command, executes it, and parses the result:

(defun gah-request-issues (repo)
  "Request issues for REPO."
  (let* ((fields gah-browser-fields)
         (cmd-list (list "gh"
                         "--repo"
                         (format "'%s" repo)
                         "issue"
                         "list"
                         "--limit"
                         (number-to-string gah-request-issue-count)
                         "--json"
                         (string-join fields ","))))

    (json-parse-string (shell-command-to-string
                        (string-join cmd-list " "))
                       :null-object nil)))

This implementation demonstrates high abstraction; the entire gah.el file consists of approximately 392 lines of code, and the basic functionality was achieved in roughly 2.5 hours.

The Philosophy of Malleable Software

Build for 1 vs. Build for N

Traditional software is typically "supply-provided," where a producer defines the feature set for a large audience (N). This often leads to software bloat, as the producer must account for the diverse needs of many users. In contrast, malleable software allows users to "build for 1," creating "just good enough" tools that satisfy their specific needs without the overhead of professional packaging, extensive documentation, or rigorous unit testing required for public distribution.

User Agency and Combinatorial Explosion

Malleable computing shifts the role of the user from a passive consumer to a co-producer. By providing building blocks (like Elisp and shell access), Emacs allows users to leverage a "combinatorial explosion" of existing libraries and programs to create new behaviors. This empowers users to solve their own problems without waiting for a producer to implement a requested feature.

Community Insights and Counterpoints

Discussion around the project highlights both the strengths and the limitations of this approach:

  • Existing Alternatives: Some users noted that Magit Forge already provides robust GitHub integration, suggesting that while building for 1 is a great exercise in agency, existing ecosystem tools often solve similar problems.
  • The "Jank" Factor: Users acknowledged that malleable tools can feel "janky" compared to polished commercial software, but argued that this is an acceptable trade-off for a workflow perfectly tailored to the individual.
  • Accessibility: There is a significant divide in the ability to utilize malleable software. As one commenter noted:

"For non technical people, malleable may as well mean complicated. We're going to see this change, but breaking this concept out of engineering is an uphill battle."

  • Architectural Parallels: The experience of building gah is compared to the vision of Lisp machines, Smalltalk, and the Unix tool model, where small, composable utilities are preferred over locked-down monoliths.

Sources