New Terminal Protocol Enables Borders Without Consuming Cell Space

Current terminal user interfaces (TUIs) often sacrifice significant screen space because borders—the lines that delineate panels and buttons—are treated as text characters. Because each character occupies a full cell, a nested layout can easily lose six to eight rows of vertical space just to decoration. A new terminal protocol, currently implemented in a Ghostty fork, solves this by treating borders as cell attributes, similar to background colors, allowing them to sit on the edges of cells without occupying any character slots.

The Limitation of Box-Drawing Characters

Standard terminal borders rely on Unicode Box Drawing blocks. Because these are text glyphs, they must occupy a full row or column of the grid. This creates a 'padding' effect where text cannot run flush against the edge of a panel, and complex layouts become cramped as the number of nested borders increases.

This image demonstrates the current standard of using box-drawing characters, which occupy full cells and create padding issues.

Beyond space constraints, box-drawing characters have aesthetic and functional limitations. For example, they cannot easily create a line between two cells that both contain content, making it difficult to underline a text field without adding extra padding. Additionally, copying text from a TUI often includes these box characters as 'junk' data in the clipboard.

“Borders are part of the problem. They have to take up space, so they become part of the panels people want to build.”

— Terminal borders that don't cost a cell | Joshka.net

Mechanism of Cell Borders

The new protocol treats a cell border as a property of the cell itself. Each cell can carry up to twelve line segments, representing the two halves of each of its four edges and four arms from its center. The terminal is responsible for rendering these segments over the grid, allowing for specific colors, widths, and styles like solid, double, dashed, or dotted lines.

This image showcases the practical application of the new protocol in a complex tiling window manager layout.

To handle overlapping lines, the protocol uses a priority system. When two neighboring cells share an edge, the terminal resolves which line to draw based on a priority score, then stroke width, and finally position (right or bottom). This ensures that a focused pane can maintain its full outline even when adjacent to other panels.

The protocol uses a Device Control String (DCS) format. Applications can set a 'pen'—similar to a background color—to define the border style for subsequent text, or use rectangle commands to apply borders to existing cells. If a terminal does not support the protocol, the application falls back to standard box-drawing characters.

This visual highlights the aesthetic and functional improvements, such as rounded corners and underlining, mentioned in the mechanism section.

Trade-offs and Implementation

The implementation in the Ghostty terminal emulator involves approximately 1,650 lines of code. Each cell is assigned a 16-bit border ID that points to a shared table of border sets. While this allows for efficient rendering, the table can occupy up to 10-15 MB of memory if every possible ID is utilized, though most TUIs only require a handful of distinct sets.

Chart drawn by HN Digest from figures reported by joshka.net; values are shown as written in the source.

Rendering performance varies by style; while straight lines are efficient, rounded corners require more processing because they are drawn as rows of small quads to achieve anti-aliasing. The author notes that while the protocol solves the space issue, it does not yet perfectly address 'half-cell' fills, which remain a separate design challenge.

This image illustrates the specific styles and line types that the protocol can render as cell attributes.