Copying TUI-displayed text includes fake line breaks from terminal wrapping

[aebrer]

Summary

When text wraps due to terminal width in the TUI, selecting and copying it with the terminal's native selection (mouse drag, etc.) includes artificial line breaks at each wrap boundary. The copied text is fragmented with \n characters that don't exist in the original content. Users should be able to copy the actual text as it is, without these wrap-induced breaks.

Current Behavior

• The TUI wraps text via wrapTextWithAnsi() in packages/tui/src/utils.ts to fit the viewport width
• When a user selects wrapped text in their terminal emulator and copies it, the clipboard receives the text with line breaks inserted at every wrap point
• The only existing copy mechanism is the /copy command (handleCopyCommand() in interactive-mode.ts), which copies the last assistant message's original text — but this doesn't help when the user wants to copy any arbitrary text (user messages, code blocks, status text, etc.)

Proposed Behavior

Provide a way to copy displayed text from the TUI that preserves the original unwrapped content, without terminal-width line breaks.

Acceptance Criteria

• Users can copy text from any message/region in the TUI without wrap-induced \n characters
• The copied text matches the original source text (before wrapTextWithAnsi was applied)
• The solution works across common terminal emulators (not dependent on specific terminal soft-wrap support)

Context

• Text wrapping implementation: packages/tui/src/utils.ts (wrapTextWithAnsi, wrapSingleLine)
• TUI Text component: packages/tui/src/components/text.ts
• Current copy command: packages/coding-agent/src/modes/interactive/interactive-mode.ts (handleCopyCommand)

Technical Notes

Possible approaches to explore:

1. TUI text selection mode — Allow keyboard/mouse navigation to select a region of the TUI; the selection logic maps back to the original Text component's source string and copies that via copyToClipboard()
2. Per-message copy commands — Extend /copy or add keybindings to copy specific messages (e.g., copy the message under cursor)
3. Terminal soft-wrap hints — Some terminals support distinguishing soft wraps from hard wraps via escape sequences, but this is not universal enough to be the primary solution

The Text component already caches the original this.text separately from the wrapped cachedLines, which could help map rendered lines back to source text.

Research note: During assessment, look up how other TUI tools (e.g., tmux, vim, neovim, kakoune, helix, lazygit) handle text selection and copying without capturing wrap-induced line breaks. Some may use internal selection buffers, OSC 52 sequences, or terminal soft-wrap signaling.

[aebrer]

Additional context from real usage:

Tool outputs are uncopyable with /copy

The /copy command only extracts text from assistant messages (getLastAssistantText()). When the workflow is:

1. User asks for a file read / grep / test run
2. dreb calls a tool
3. Tool output is displayed in the TUI
4. dreb follows up with commentary about the tool result

…then /copy copies the commentary (step 4), not the actual tool output (step 3) that the user wanted. This makes /copy useless for the most common "give me that output" scenario.

This strengthens the case for a TUI-level selection/copy mechanism that can target any rendered content — assistant messages, tool outputs, status text, errors — rather than being limited to the last assistant message's text content.

[aebrer]

Issue Assessment — TUI Text Copy Without Wrap-Induced Breaks

1. Summary

The core problem is architectural: dreb's TUI destroys the original text structure at render time. wrapTextWithAnsi() and Markdown.render() transform source text into terminal-width lines with hard breaks, padding, and ANSI codes. The /copy command bypasses this by reading from the session's message array, but it's limited to the last assistant message's text blocks only. Tool outputs, user messages, code blocks within messages, and partial selections are all unreachable.

This is not a rendering bug — it's a missing capability: the TUI has no mechanism to map rendered screen content back to its source text, and no selection model to let users target arbitrary content.

---

2. Current State

Text wrapping (the source of fake breaks):

• packages/tui/src/utils.ts — wrapTextWithAnsi() splits text into ≤ width visible-character lines. It handles ANSI code tracking across breaks, word wrapping, and long-word breaking. Once wrapped, the original line structure is gone.
• packages/tui/src/components/text.ts — Text.render() calls wrapTextWithAnsi(), then adds padding margins and background colors.
• packages/tui/src/components/markdown.ts — Markdown.render() tokenizes via marked, applies ANSI theming, then wraps into terminal lines.

Component model (opaque black boxes):

• packages/tui/src/tui.ts — Container.render() iterates children, calls child.render(width), and concatenates string[] lines. There is no tracking of which child produced which lines, or how many lines each child contributed.
• TUI.doRender() compares previousLines vs newLines for differential updates. previousLines is a flat string[] with no metadata.

Current copy mechanism (blunt instrument):

• packages/coding-agent/src/modes/interactive/interactive-mode.ts — handleCopyCommand() calls session.getLastAssistantText(), which walks agent.state.messages in reverse and concatenates content.text blocks from the last assistant message.
• packages/coding-agent/src/core/agent-session.ts — getLastAssistantText() explicitly skips tool results, user messages, and non-text content.

Message rendering in interactive mode:

• packages/coding-agent/src/modes/interactive/components/assistant-message.ts — AssistantMessageComponent renders text and thinking blocks as Markdown children.
• packages/coding-agent/src/modes/interactive/components/user-message.ts — UserMessageComponent wraps user text in Markdown with OSC133 shell integration markers.
• packages/coding-agent/src/modes/interactive/components/tool-execution.ts — ToolExecutionComponent renders tool calls/results via custom renderers or fallback Text. Tool output text is assembled from result.content arrays.

Existing selection:

• The TUI has SelectList and SettingsList for list-item selection (arrow keys + confirm), but no free-form text selection mechanism.
• packages/tui/src/keybindings.ts — tui.input.copy (Ctrl+C) is defined but the editor treats it as a no-op, letting the parent handle it. tui.select.* bindings exist for list navigation, not text selection.

---

3. Gaps

Gap	Impact
No line-to-component mapping	Cannot determine which message/component produced a given screen line
No component source-text API	Component.render() returns string[] only; no way to query the original unwrapped text
/copy only reads last assistant message	Tool outputs, user messages, earlier assistant messages are completely unreachable
No selection mode	Users cannot highlight arbitrary text regions in the chat history
Single focus target	The editor owns focusedComponent; any selection mode must coexist or temporarily displace it
Wrapping is destructive	wrapTextWithAnsi() output cannot be reverse-mapped to source without reconstructing the algorithm

---

4. Ambiguities

These should be resolved before implementation planning:

1. Selection granularity: Whole message? Individual code block? Free-form region (arbitrary start/end lines)? Vim-like visual mode?
2. Copy output format: Plain text only? Preserve markdown syntax? Strip ANSI? What about thinking blocks — include or exclude?
3. Tool output scope: Copy the raw result.content JSON/array? The rendered text? What about image tool results?
4. Keyboard vs. mouse: Is this keyboard-driven (e.g., enter selection mode, navigate, copy)? Should it support terminal mouse events?
5. Focus interaction: If user is typing in the editor and hits a selection keybinding, what happens to their draft?
6. Scope creep: Should this also enable "copy URL from link" or "copy code block without backticks"?

---

5. Scope Estimate

Medium–Large. This is not a localized fix. It requires:

• New infrastructure in @dreb/tui for tracking rendered-line provenance OR exposing source text from components
• A selection model (even if whole-message-only initially)
• Integration into InteractiveMode for message-level selection
• Extension of /copy or new keybindings for triggering copy on selected content
• Handling edge cases: tool outputs, thinking blocks, streaming content, collapsed/expanded tool results

A minimal viable version (whole-message copy via keyboard navigation) is Medium. A full free-form selection mode is Large.

---

6. Risks

Risk	Severity	Mitigation
Performance: adding line tracking to Container.render() could slow differential rendering	Medium	Track offsets lazily, only when selection mode is active; or maintain a parallel index rebuilt on render
Focus conflicts: selection mode competing with editor for input	Medium	Use overlay or modal approach; restore editor focus on cancel
Component API breakage: requiring all components to expose source text	Medium	Make it optional; fallback to rendered text stripping for legacy components
Tool output complexity: custom renderers may not have a clean "copyable text" representation	Medium	Fall back to getTextOutput() / formatToolExecution() for tool components
Streaming content: copying a message that's still being rendered	Low	Lock selection to completed messages, or re-resolve source on copy

---

7. Comparative Research Summary

tmux — Had the exact same bug (issue #4995). Fixed by tracking GRID_LINE_WRAPPED on the backing grid so copy-selection and capture-pane -J can join wrapped lines. Also added -T to trim trailing padding spaces.

vim / neovim / helix / kakoune — The 'wrap' option is purely visual. Yanking (y) always reads from the buffer model, never the screen cells. Navigation by screen lines (gj/gk) moves the cursor visually but selection boundaries remain tied to buffer coordinates.

lazygit — Copies source data (commit messages, diff text) rather than rendered screen cells. Copied diffs include +/- markers, confirming it copies the underlying text, not a cleaned display representation.

Terminal soft-wrap escape sequences — No standard ANSI/OSC sequence exists for an application to mark a line as "soft wrapped." DECAWM only controls whether wrapping happens at all. The solution must be entirely application-side.

OSC 52 — Standard clipboard transport that works over SSH. dreb already uses it in copyToClipboard(). The application is responsible for preparing correctly joined text before emitting it.

Bottom line from research: The solution is architectural, not protocol-based. Separate the rendered view from the content model, track wrap metadata internally, and ensure the copy engine reads from the content model.

---

8. Recommended Next Steps

1. Decide on selection granularity — whole-message keyboard navigation is the smallest viable scope
2. Design a source-text API for components — e.g., Copyable interface with getCopyText(): string
3. Instrument Container.render() or add a provenance index — map screen line ranges to their producing components
4. Prototype whole-message copy — extend /copy or add a keybinding to copy the message at a navigable cursor position
5. Iterate to finer granularity — code blocks, partial selections

---

Automated assessment by mach6