zterm: a terminal core built to travel

A terminal emulator has to do two jobs at once. It interprets a stream of terminal control sequences and it presents the resulting grid through a window system. Those concerns are often intertwined, which makes a second display backend a substantial rewrite. zterm takes a different route: it is a small terminal emulator in Zig whose terminal model and input encoding are separated from its X11 display implementation.

The project arrived in a single substantial initial commit on 2026-08-16 (730cbf6): 26 files and 4,672 inserted lines, including a parser, terminal grid, UTF-8 decoder, character-width tables, pseudo-terminal support, input encoding, and an X11/Xft frontend. The README describes a running shell with xterm-256color behavior, standard colors and text attributes, alternate screen, cursor and scrolling controls, title reports, paste modes, and resize handling. The project targets Zig 0.16, links Xlib, Xft, fontconfig, and libc at runtime, and runs on Linux under X11 or XWayland.

One design choice is to keep src/term/ and src/input.zig free of X11 dependencies. The backend interface is a vtable with a pollable file descriptor. That gives future backends a seam to attach to without splitting the terminal implementation. The codebase currently contains one display backend, X11; a Wayland backend is an architectural possibility, not a shipped feature. Input bytes are selected in the core because the correct key sequence depends on terminal modes such as application cursor mode, not on how a window reports a keypress.

A particularly concrete engineering episode is documented in the README’s font fallback notes. When a glyph is absent from the configured font, fontconfig searches for a candidate seeded with the configured family so fallback glyphs retain a monospace face. Even then, a candidate can claim to have a glyph that Xft cannot actually draw. The documented case is COLRv1-only color emoji fonts: a presence check can succeed while rasterization leaves no pixels. zterm probes the glyph offscreen and tries another candidate when the probe stays blank. It also retains a charset check, because a missing glyph can render a visible .notdef box and falsely look like success. This records a practical failure mode and the layered checks used to distinguish it.

There is a tradeoff: the renderer uses font glyphs for box-drawing and block characters. If a fallback font advances by a different width than the cell, line segments can show gaps and a full block may not fill the cell. The README calls this out as a known issue and identifies procedural rectangle drawing as a way to address it. The project is also explicit about missing features such as scrollback, selection, mouse reporting, resize reflow, and image protocols. Those boundaries make the current scope legible to contributors and users.

The terminal core has 52 Zig unit tests, covering areas such as parser sequences, cursor and grid behavior, UTF-8 validation, display width, and key encoding. The README says these tests need no display. The tracked Zig source totals 4,004 lines. The repository history is small: three commits overall, of which two are managed documentation synchronizations on 2026-08-29 and 2026-09-05. There are no issue or study files in the checkout before this report. Its initial commit includes the harnez harness and coding conventions, but the available repository evidence does not show ticket work, sprint or advisor runs, feedback reports, or parallel agents. It would overstate the record to attribute the implementation to a particular agent workflow.

That distinction is useful when talking about agentic development. zterm demonstrates a compact but broad implementation—protocol parsing, terminal state, Unicode edge cases, a PTY, and a native display frontend—with a testable seam between core and platform. The commit establishes that this breadth was assembled at once, and the source gives readers concrete mechanisms to inspect. The available evidence does not show how many people or agents produced it, so the strongest claim is about the engineering shape: modular boundaries and focused core tests make a specialized systems project easier to extend and reason about.

Facts