Prior Art and Project Evidence¶
Status: living research note
Last reviewed: 2026-09-25
This document compares selected terminal mechanisms and application designs that inform the project’s content model, history behavior, and test scenarios.
Protocol and terminal mechanisms¶
Work |
Content model |
Historical mutation |
Reading-anchor semantics |
Relevance |
|---|---|---|---|---|
Stateful character-imaging controls |
No stable application-level block mutation |
None for logical content |
Establishes the byte-stream and active-screen baseline |
|
Prompt, command, and output boundaries |
No general replacement operation |
Navigation between marks, not mutation anchoring |
Demonstrates deployed semantic marking |
|
Sanitized HTML inserted into a DOM-backed terminal |
Replaces the latest keyed replaceable element |
No general terminal-native history policy is specified |
Demonstrates keyed historical replacement |
|
Identified MIME content blocks |
|
No terminal-native reading-anchor behavior is specified |
Closest block lifecycle, fallback, capability, and trust design |
|
Identified start/end regions |
Existing blocks can be folded or unfolded |
No arbitrary content replacement anchor |
Demonstrates deployed block identity and limited updates |
For this project, SpaceTerm is the closest prior-art design reference. Its protocol provides designs for:
block identity and live-block lifecycle;
capability negotiation;
plain-text fallback;
rich representation selection;
trust tiers;
in-band and optional side-channel transport.
SpaceTerm describes itself as a web-native terminal, and its core models scrollback as a block list. The remaining comparison is whether TBP can be extended or profiled to define mutation and anchor behavior for terminal-owned history with terminal-native interaction.
Application architecture evidence¶
Project |
Approach |
Observed trade-off |
|---|---|---|
Skips repaint only for same-line-count, image-free changes above the viewport |
Avoids destructive redraw in a provable subset but explicitly accepts stale scrollback; layout changes retain the destructive baseline |
|
Documents scrollback clearing during full redraw |
Removing the clear alone does not provide historical identity or safe replay semantics |
|
Documents the main-screen constraint: scrollback can only be appended to or fully cleared, so a reflow above the viewport forces a destructive redraw |
Closed as completed the same day; the maintainer’s answer was the experimental alternate-screen renderer, declared intended to become the default |
|
Application-owned document, scrolling, selection, and follow mode |
Controls reflow and updates but moves live history out of terminal-native scrollback |
|
Records the alternate-screen cost: large transcripts re-render every frame and each resize re-emits the whole transcript |
Open at review time; the application-owned transcript’s performance tail remains active upstream work |
|
Retired a transcript-owned viewport experiment (82,802 deleted lines) |
Strong rewrap and copy behavior came with a cross-environment compatibility matrix; the stated successor keeps scrolling, selection, and copy terminal-native |
|
Opt-in alternate-screen, application-owned transcript |
Reimplements scrolling, selection, search, and export; classic mode retains native scrollback |
Kimi Code also records the failed general redraw chain:
PR #1367 names the structural cause: the fork’s anchor pinned buffer row indices while content shifted underneath, so interacting edge cases accumulated faster than they could be stabilized; the revert knowingly re-accepts the destructive-redraw symptom. The failure classes reported by that chain are requirements for this project’s test oracle: blank screens, duplicated scrollback spans, vanished rows, growing blank space, and incorrect cursor bookkeeping.
Pi’s tracker disposition is further evidence: later reports of the same main-screen symptom (#8465, #9240, #9424, #9769, and #10030) were closed as not planned. A contributor comment on #8465 frames the remaining options as alternate-screen rendering or terminal-protocol changes; no maintainer endorsement of the protocol direction is on record.
Current conclusion¶
The surveyed mechanisms cover pieces of the problem:
semantic boundaries without general mutation;
keyed mutation in DOM or block-list terminals;
application-owned history with controllable reflow;
terminal-native history with frozen or destructively replayed offscreen content.
No surveyed source currently specifies all three target properties together: terminal-owned native history, correct mutation after content leaves the active screen, and preservation of a logical reading anchor.
The project uses an independent logical protocol because its baseline concerns terminal-owned mutable history and reading-anchor preservation rather than a bundle of rich representations. It reuses the demonstrated deployment pattern of OSC carrying Base64-encoded structured data without adopting TBP’s content model or patch semantics.