Part of the cross-platform UI crate (see `docs/UI_CRATE_DESIGN.md`).
What
A way for apps to stream new lines into a `TextDisplay` (or similar read-only text viewer) without rebuilding the entire buffer each frame.
- App calls `text_display.append_line(...)` when new data arrives from a channel
- Only the appended slice invalidates; rest of the view stays put
- Optional auto-scroll to bottom (disable while user is scrolling up, re-enable on scroll-to-bottom)
- Optional max-line-retention (ring buffer for log viewers)
- Works in TUI (partial redraw) and GUIs (partial repaint)
Why
The Terminal primitive already handles streaming for PTY output, but non-terminal use cases need this too:
- LSP trace log viewer
- DAP debug console output
- Extension/plugin log tails
- k8s pod logs
- SQL query execution history
The current vimcode pattern of rebuilding the whole buffer text each frame would work but doesn't scale to high-volume streams (log tails, kubectl logs -f).
Acceptance
- API on `TextDisplay`: `append_line()`, `clear()`, `set_max_lines()`, `auto_scroll` toggle
- Efficient backend impl (diff only new region)
- Benchmark: 10k lines/sec append with no visible jank in TUI and GUI backends
Scope note
Low priority until a vimcode feature (or other app) actually streams at volume. LSP traces today are low-volume and polling-based.
Part of the cross-platform UI crate (see `docs/UI_CRATE_DESIGN.md`).
What
A way for apps to stream new lines into a `TextDisplay` (or similar read-only text viewer) without rebuilding the entire buffer each frame.
Why
The Terminal primitive already handles streaming for PTY output, but non-terminal use cases need this too:
The current vimcode pattern of rebuilding the whole buffer text each frame would work but doesn't scale to high-volume streams (log tails, kubectl logs -f).
Acceptance
Scope note
Low priority until a vimcode feature (or other app) actually streams at volume. LSP traces today are low-volume and polling-based.