What changed / requested behavior
Render long or multiline paste placeholders such as [Pasted text #1 +12 lines] as highlighted semantic spans in the TUI composer, similar to image/file markers, and treat each placeholder as one logical editing unit.
At minimum:
- A placeholder backed by stored pasted text is visually highlighted, making it clear that the full payload was captured and remains attached.
- Option/Alt+Backspace with the cursor after the placeholder removes the entire placeholder in one action rather than deleting
lines], +12, #1, etc. word by word.
- Word-left/word-right navigation treats the placeholder as one unit rather than entering its display text.
- Removing the semantic span detaches its hidden paste body.
- Manually typing an identical-looking string must remain ordinary text and must not reattach a previously removed hidden payload.
- Multiple pasted spans retain independent identity and expand to their corresponding bodies exactly once on submission.
Scope: terminal TUI/readline behavior only; no GUI changes.
Why
Long/multiline paste content is currently stored out of band while a plain editable string is inserted into the composer (src/readline.zig). Submission finds that exact string and replaces it with the hidden body. This creates two confusing behaviors:
- The placeholder looks like ordinary text, so users cannot tell whether it still represents intact pasted content or has been partially corrupted by editing.
- Generic word deletion treats one paste attachment as several words even though it is conceptually one object.
There is also an identity problem: deleting the full placeholder does not remove its backing record during the same prompt. Manually reconstructing the exact marker currently makes submission expand the old hidden paste again. Highlighting alone would not solve that; the composer needs to track a live semantic span/attachment rather than infer attachment identity from matching display text.
Images and selected file paths already establish the visual language for highlighted composer spans. Reusing that language makes a highlighted paste marker mean “this hidden payload is present and intact,” while an unhighlighted lookalike is visibly just text.
Constraints and trade-offs
- Do not put the full multiline body back into the visible composer; the compact placeholder is still useful.
- Preserve the exact pasted bytes used for submission, including multiline content.
- Styling must follow the existing TUI marker/highlight treatment and remain readable in both terminal themes.
- Avoid relying only on string matching: presentation text is not a stable attachment identity.
- Keep ordinary text editing and short single-line paste behavior unchanged.
Acceptance checks
- Paste 12 lines: one highlighted
[Pasted text #1 +12 lines] span appears.
- Press Option/Alt+Backspace immediately after it: the complete span and its payload are removed in one action.
- Delete the span, manually type
[Pasted text #1 +12 lines], and submit: the literal string is sent; the removed body is not resurrected.
- Paste two bodies: deleting one leaves the other highlighted and expands only the surviving payload.
- Move by words across a paste span: the cursor lands before or after it, never inside it.
What changed / requested behavior
Render long or multiline paste placeholders such as
[Pasted text #1 +12 lines]as highlighted semantic spans in the TUI composer, similar to image/file markers, and treat each placeholder as one logical editing unit.At minimum:
lines],+12,#1, etc. word by word.Scope: terminal TUI/readline behavior only; no GUI changes.
Why
Long/multiline paste content is currently stored out of band while a plain editable string is inserted into the composer (
src/readline.zig). Submission finds that exact string and replaces it with the hidden body. This creates two confusing behaviors:There is also an identity problem: deleting the full placeholder does not remove its backing record during the same prompt. Manually reconstructing the exact marker currently makes submission expand the old hidden paste again. Highlighting alone would not solve that; the composer needs to track a live semantic span/attachment rather than infer attachment identity from matching display text.
Images and selected file paths already establish the visual language for highlighted composer spans. Reusing that language makes a highlighted paste marker mean “this hidden payload is present and intact,” while an unhighlighted lookalike is visibly just text.
Constraints and trade-offs
Acceptance checks
[Pasted text #1 +12 lines]span appears.[Pasted text #1 +12 lines], and submit: the literal string is sent; the removed body is not resurrected.