Evaluate libghostty-vt as the terminal core #13

New issue

Open

opened 2026-08-19 23:56:56 +00:00 by dusan · 0 comments

dusan commented

2026-08-19 23:56:56 +00:00

Owner

Context

Terminalko renders terminals with VTE (vte-2.91-gtk4, LGPL-2.1+), through
the vte4 crate. That choice is the foundation of the project: it is why the
plan chose Rust in the first place — the terminal core is a mature C library and
the novelty is everything around it (docs/spec/session-agent.md).

libghostty-vt is Ghostty's terminal core, extracted as a zero-dependency library
with a C ABI: escape-sequence parsing, grid, scrollback, reflow, input encoding.
It is MIT, which suits this project's BSD-2 licence better than LGPL does.

The question

Is there a reason to move? This is research, not implementation, and the honest
default is no. What would have to be true for it to be worth it:

Full scrollback across restarts. Today the agent replays a 2 MiB ring buffer
when a window reattaches, and cannot do better because VTE's grid lives in the
window and dies with it (docs/spec/session-agent.md). If the agent owned a
libghostty grid instead, a reattaching window could be handed the real
scrollback. That is the one capability VTE cannot give, and it is a significant
one for a program whose selling point is sessions outliving windows.
Rendering: Terminalko would have to draw the grid itself — GTK4 render nodes or
a GL area — which is a large amount of work VTE currently does, including font
fallback, ligatures, bidi, selection, accessibility and IME.

What this issue asks for

A written comparison, not code:

What libghostty-vt's API can and cannot do today, and whether it is stable —
as of writing, upstream says the API is explicitly not stable yet.
What Terminalko would have to implement itself: enumerate what VTE gives us by
listing every TerminalExt method the code calls
(crates/terminalko/src/terminal.rs and page.rs) and saying what replaces
each.
Whether the agent-owns-the-grid design is feasible: who holds the grid, what
crosses the socket (an updated grid rather than raw bytes changes the protocol
fundamentally), and what happens to the "VTE reads the pty directly while
attached" property that keeps output off the IPC path today.
A recommendation with a decision, recorded in docs/spec/.

Acceptance criteria

A document in docs/ that someone can read and decide from, including the list
in point 2 — the useful part, and the part that says how large this is.
No code changes unless the recommendation is to proceed, in which case a
separate issue per step.

Notes

https://libghostty.tip.ghostty.org/
https://mitchellh.com/writing/libghostty-is-coming
Ghostty is MIT: reading it is allowed, unlike GPL terminals. See
CONTRIBUTING.md.

## Context Terminalko renders terminals with **VTE** (`vte-2.91-gtk4`, LGPL-2.1+), through the `vte4` crate. That choice is the foundation of the project: it is why the plan chose Rust in the first place — the terminal core is a mature C library and the novelty is everything around it (`docs/spec/session-agent.md`). `libghostty-vt` is Ghostty's terminal core, extracted as a zero-dependency library with a C ABI: escape-sequence parsing, grid, scrollback, reflow, input encoding. It is MIT, which suits this project's BSD-2 licence better than LGPL does. ## The question Is there a reason to move? This is research, not implementation, and the honest default is **no**. What would have to be true for it to be worth it: * **Full scrollback across restarts.** Today the agent replays a 2 MiB ring buffer when a window reattaches, and cannot do better because VTE's grid lives in the window and dies with it (`docs/spec/session-agent.md`). If the *agent* owned a libghostty grid instead, a reattaching window could be handed the real scrollback. That is the one capability VTE cannot give, and it is a significant one for a program whose selling point is sessions outliving windows. * Rendering: Terminalko would have to draw the grid itself — GTK4 render nodes or a GL area — which is a large amount of work VTE currently does, including font fallback, ligatures, bidi, selection, accessibility and IME. ## What this issue asks for A written comparison, not code: 1. What libghostty-vt's API can and cannot do today, and whether it is stable — as of writing, upstream says the API is explicitly **not** stable yet. 2. What Terminalko would have to implement itself: enumerate what VTE gives us by listing every `TerminalExt` method the code calls (`crates/terminalko/src/terminal.rs` and `page.rs`) and saying what replaces each. 3. Whether the agent-owns-the-grid design is feasible: who holds the grid, what crosses the socket (an updated grid rather than raw bytes changes the protocol fundamentally), and what happens to the "VTE reads the pty directly while attached" property that keeps output off the IPC path today. 4. A recommendation with a decision, recorded in `docs/spec/`. ## Acceptance criteria - A document in `docs/` that someone can read and decide from, including the list in point 2 — the useful part, and the part that says how large this is. - No code changes unless the recommendation is to proceed, in which case a separate issue per step. ## Notes - <https://libghostty.tip.ghostty.org/> - <https://mitchellh.com/writing/libghostty-is-coming> - Ghostty is MIT: reading it is allowed, unlike GPL terminals. See `CONTRIBUTING.md`.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

dusan/terminalko#13

No description provided.

Rows
Columns