Loom: building a terminal UI library in fast, testable slices

Loom is a Go library for building terminal interfaces from reusable widgets. It began as shared UI code extracted from the uzu project; its purpose now is to let independent command line tools reuse the same input, layout, rendering and interaction behavior. The interface runs inline in the current terminal instead of taking over the full screen. That makes terminal restoration and careful cursor behavior part of the product, alongside familiar widgets such as tables and text inputs.

The repository has grown into a broad toolkit: declarative YAML layouts, a library of interactive widgets, terminal drawing and composition primitives, a syntax engine, example applications, and command line tools. In the six weeks through 2026-10-04, Git records 1,227 commits. The tree contains 336 Go source files and 1,243 test functions. Those numbers include extensive issue and study documentation as well as implementation work; they show the scale of iteration, rather than measuring unique features.

The newest visible example is RichTextEdit, a styled text editor built for terminal cells. Across issues 254–264, work added document rendering, selection, inline styles, pills, word operations, clipboard and undo/redo behavior, a format popover, color palettes, clickable links in view mode, box drawing, and keyboard navigation. Release v0.3.0 was recorded on October 3. The following day’s commits refined editing behavior and the gallery demonstrations. A specific early milestone added document and ANSI serialization (1134365); a later one added the viewport renderer (1c706e2).

One hard episode shows why a widget library needs end-to-end reasoning. RichTextEdit could choose a bar cursor for normal typing and a block cursor for box drawing. Yet when the editor ran inside the gallery’s tabs and wrapper, the terminal cursor never changed. Issue 264’s investigation followed the shape request through the nesting: the pane only asked the unwrapped root widget, while the editor was a deeper child. The fix routed cursor shape through the canvas that already carries the cursor position (d4616a0), then implemented popover submenu navigation (ac08b50). The issue records the observable acceptance check: terminal escape sequences for bar and block modes, followed by restoration on exit. It also records host test reruns and a live check in Tilix. That sequence tied API design, container behavior, terminal protocol output and a real terminal check to one issue.

The project’s issue tracker supports this style of work. Tickets include priority and severity, a scoped problem, technical findings, milestone acceptance details, and delivery evidence. In the last week of the activity window, issues 254–264 document successive editor milestones and feedback-driven refinements. The repository’s Harnez studies describe two complementary agent workflows: a September 20 lean sprint delegated seven scoped tickets to named harnez agent workers, and the October 1 module migration recorded changes across eight dependent repositories. The migration report is unusually instructive because it names review catches: one worker mapped a quit result to “handled,” while another returned “ignored” after a state-changing action. Tests and host review caught both semantic mistakes.

That is a more grounded account of agentic development than treating a high commit count as proof of autonomy. Small tickets and explicit milestone checks made work parallelizable; reviewers still had to understand the library’s contracts and judge live behavior. The scale here is visible in the combination: 1,243 test functions, more than 260 numbered issues, and a six-week history that includes API migration, gallery expansion, event routing, terminal rendering and a rich text editor. A single developer might build any one of those features. Coordinating and maintaining that breadth while also supporting dependent repositories would be difficult without disciplined issue tracking, automated tests and agent workstreams.

Loom is aimed at developers who need reliable terminal interfaces without adopting a full-screen application framework. For a public project page, the strongest story is not simply that agents wrote code quickly. It is that a shared library made its contracts explicit enough for workers to build in slices, and used tests, issue reviews and terminal checks to catch mistakes at the boundaries between widgets and real terminals.

Facts