Copy sometimes does nothing, and never says so

[jamescrosswell]

Opportunity

Copy can do nothing at all, and look exactly like it worked.

You select text, press Cmd+C, switch to another window, paste — and get whatever was on the
clipboard before. The editor gives no sign: no message, no error, the selection still highlighted.
The maintainer hit this in iTerm2 selecting a whole file with Ctrl+A; a smaller selection of the
same file copied fine (the Original idea below).

The cost isn't the one lost copy. It's that after this happens once you stop trusting copy and
start checking every paste — in the editor the vision wants to be a daily driver.

Evidence — TuiCode never looks at whether the copy landed:

• Both copy paths end in the same fire-and-forget call: TuiCode's multi-caret copy
  (EditorTextView.Carets.cs:254)
  and, at a single caret, Terminal.Gui's own TextView.Copy, both do
  App?.Clipboard?.SetClipboardData(text). It returns void, the ?. swallows a missing
  clipboard entirely, and nothing checks afterwards that the text arrived.
• Terminal.Gui offers IClipboard.IsSupported and TrySetClipboardData for exactly this. TuiCode
  uses neither.
• IsSupported is not trustworthy anyway. MacOSXClipboard decides by shelling out to
  which pbcopy; under dotnet test on the maintainer's Mac it reported False while
  /usr/bin/pbcopy was sitting right there — and writing through that same "unsupported"
  clipboard worked. So the check we'd naturally reach for would have disabled copy here.
• The size theory doesn't hold. Driving NSPasteboard through the same Objective-C calls
  Terminal.Gui makes, an 86 KB buffer round-trips byte-for-byte, as does CONTRIBUTING.md (5.8 KB).
  Through TG's own MacOSXClipboard: 86,889 characters in, 86,889 out, identical. Whatever ate
  that copy, it was not macOS refusing the text — so there is no cap to raise, and no reproduction
  to work from until copy starts reporting failure.
• Copy over SSH is a separate hole (there is no local clipboard at all): that's Make native OS shortcuts (Cmd+C/V/X etc.) work across different terminal emulators #40's, and this
  pitch stays local.

Options considered

1. Document it and move on. Cheapest. But there is nothing to document — no reproducible
   limit, and no workaround to offer beyond "copy less at a time". Leaves the maintainer checking
   every paste.
2. Hunt the size cap. Bisect buffer size until copy fails, raise whatever bites. Targeted and
   satisfying if it exists — but the measurements above say the OS clipboard takes 86 KB happily,
   so this is most likely chasing a ghost, and it leaves every other silent-failure mode (no
   clipboard, a clipboard that throws, a remote session) exactly as it is.
3. Make copy prove itself, and say what happened. (Proposed.) Write, read back, compare, and
   tell the user in the status bar — Copied 141 lines • 5,835 selected, or a one-line error naming what
   failed. Where the read-back doesn't match, fall back to the platform's own tool (pbcopy,
   xclip/wl-copy, clip.exe) and check again. Fixes the class rather than the instance, and
   turns this bug from a mystery into a message the maintainer can act on.
4. Take the clipboard over completely. Drop App.Clipboard, write TuiCode's own per-platform
   clipboard plus OSC 52 for SSH. The most complete answer — and most of Make native OS shortcuts (Cmd+C/V/X etc.) work across different terminal emulators #40 as well, which is a
   lot to sign off on the back of one bug report. Option 3 is its first slice if we go there.

Proposal

Copy never fails silently.

Copy and cut — one caret or many, editor or diff — go through one clipboard service:

1. Write, then verify. After setting the clipboard, read it back and compare with what we sent.
   Read-back is the check, not IsSupported, which lies.
2. Fall back once. If the read-back doesn't match, retry through the platform's own tool
   (pbcopy / wl-copy / xclip / clip.exe) and verify again.
3. Say what happened, in the status bar. On success, what was copied. On failure, one line
   naming which clipboard refused it — the first line of the tool's stderr, never an exception type
   (style guide: outside a
   dialog, errors go to the status bar).

Mockup

StatusBarPart message area. The separator is • (StatusBarPart.DefaultMessage and its
string.Join), and the right-hand readout is StatusBarPart.ShowPosition's own
Ln R, Col C (N selected) — not invented here.

After a successful copy — replaces the file path, reverting to it after a few seconds
(ClearMessage, as Save already does):

 Copied 141 lines  •  5,835 characters              Ln 1, Col 1 (5,835 selected)

After a copy that didn't land — Error scheme, stays until the next message:

 Copy failed: the clipboard didn't take the text (pbcopy)   Ln 1, Col 1 (5,835 selected)

No new controls, no dialog: a copy the user didn't ask to be told about must not open a modal.

Scope

In

• One clipboard service used by every copy and cut path, including the single-caret one that
  currently falls through to TextView.Copy.
• Write-then-read-back verification, and the fallback to the platform tool.
• Status bar messages for both outcomes.

Out

• OSC 52 and copy over SSH (Make native OS shortcuts (Cmd+C/V/X etc.) work across different terminal emulators #40).
• Paste. Paste failing is visible — nothing appears — so it isn't the same problem. If the same
  service makes it free, fine; it isn't a goal.
• Clipboard history, multiple clipboards, a clipboard viewer.
• Any Settings UI. There is nothing here for the user to configure.

Rough breakdown

1. Copy tells you what it copied, and tells you when it didn't. One clipboard service behind
   both copy paths; write, read back, compare; status bar message either way. After this merges,
   this bug either stops happening or produces a reportable error instead of silence.
2. Copy falls back to the platform's own clipboard tool. When the read-back doesn't match,
   retry through pbcopy / wl-copy / xclip / clip.exe. A copy that used to vanish now lands.
3. (Only if 1 and 2 leave large copies failing) Own the clipboard — option 4: TuiCode's own
   per-platform clipboard in place of App.Clipboard, with OSC 52 from Make native OS shortcuts (Cmd+C/V/X etc.) work across different terminal emulators #40 folded in. Copying a
   whole large file has to work; if the messages from 1 and 2 show the stock clipboard can't do it
   reliably, this is the fix rather than patching whatever the message names.

Decided

1. Announce every successful copy — reviewer agreed. The message reverts to the file path.
2. Read back on every copy — reviewer agreed. Measure on a large buffer; revisit only if
   noticeable.
3. If large copies still fail after slices 1–2, go to option 4 — reviewer: copying big
   portions of text has to work, so owning the clipboard (with Make native OS shortcuts (Cmd+C/V/X etc.) work across different terminal emulators #40's OSC 52) is on the table.
   It's slice 3, gated on what slices 1–2 report.

Original idea

In iTerm2, if I open a reasonably large file like the CONTRIBUTING.md file in this repository and press Ctrl + A and then Ctrl + C to copy everything... nothing gets copied to the system clipboard.

If I copy a smaller subsection of the document, it copies successfully.

Is this specific to iTerm? Is it a bug or a configuration setting? Is there any way around this?

[jamescrosswell]

Drafted this as a pitch (Exploring — it'll come to you once there's a slot in Pitched).

One thing worth flagging now: I couldn't find a size limit. Through the same macOS clipboard
Terminal.Gui uses, 86,889 characters round-trip byte-for-byte; CONTRIBUTING.md does too. So I
retitled it — the size looks incidental, and the real problem is that both copy paths end in
App?.Clipboard?.SetClipboardData(...) and never check whether the text landed.

Also: TG's IsSupported reported False on your Mac while /usr/bin/pbcopy was right there, and
writing through that "unsupported" clipboard worked anyway. So the proposal verifies by reading
back, not by asking TG whether it can.

[jamescrosswell]

Promoted to Pitched — there was room, nothing had to be displaced.

I re-checked the draft against current origin/main (0f2681d) before putting it in front of you. The evidence still holds: the multi-caret copy is still fire-and-forget (App?.Clipboard?.SetClipboardData(_copiedText), now EditorTextView.Carets.cs:254 — the link has been re-pinned to a commit so it stops drifting), nothing in src/ calls TrySetClipboardData or checks the write, and the single-caret path still falls through to TG's own TextView.Copy.

Two things in the mockup were wrong and I've corrected them, since the pitch asks you to judge an on-screen experience:

• I'd written the separator as ·. The status bar actually uses • everywhere (StatusBarPart.DefaultMessage, and the string.Join in ShowPosition's sibling).
• I'd invented the right-hand readout as 5835 sel. StatusBarPart.ShowPosition really renders Ln 1, Col 1 (5,835 selected), which is what the mockup now shows.

The three open questions are unchanged and are the ones I'd most like your call on — particularly the first, whether every successful copy gets a status line or only large ones.

[jamescrosswell]

• Announce every successful copy, or only large ones? A message on every Cmd+C could read as
  noise. My recommendation: every copy, because the message area is otherwise showing the file
  path and reverts to it — and a visible confirmation is the whole point when trust is what broke.

Every copy

• Is a read-back on every copy acceptable? It costs a second clipboard round trip, and on
  Linux the fallback path means spawning a process. My recommendation: verify always, measure on a
  large buffer, and revisit only if it becomes noticeable.

Agreed.

• If it still reproduces once copy reports properly, do we go to option 4 — own the clipboard
  outright and fold in Make native OS shortcuts (Cmd+C/V/X etc.) work across different terminal emulators #40's OSC 52 — or fix whatever the message names?

Yes we want to be able to copy big portions of text so if that's necessary, we should consider it.

[jamescrosswell]

Thanks — folded in:

• Open questions → Decided: every copy is announced; read-back on every copy.
• Slice 3 is now option 4 (own the clipboard, with Make native OS shortcuts (Cmd+C/V/X etc.) work across different terminal emulators #40's OSC 52), taken only if large copies still fail once slices 1–2 report what's happening.

Left in Pitched for you to approve.

[a-team-app]

Broken down. Expected order:

1. Copy tells you what it copied, and tells you when it didn't #318 — copy/cut verifies by reading back and says Copied N lines • M characters or Copy failed: … in the status bar. A failed cut keeps the text.
2. A copy the clipboard refuses lands anyway, through the system's own clipboard tool #319 — if the read-back doesn't match, retry once via pbcopy / wl-copy / xclip / clip.exe. Blocked by Copy tells you what it copied, and tells you when it didn't #318 (same code path).

All three open questions were already settled by you; nothing assumed.

Slice 3 (own the clipboard + #40's OSC 52) isn't filed yet. It depends on what 1–2 report, so I'll file it at validation if a large copy still fails.

[a-team-app]

Validated #318 and #319 on origin/main (7877e3b), driving the app in tmux on macOS:

• Ctrl+A, Ctrl+C on CONTRIBUTING.md → Copied 95 lines • 6,341 characters; the clipboard matched the file byte for byte. Message reverted to the path after a few seconds; the (6,341 selected) readout was unchanged.
• No selection → Copied 1 line • 187 characters, whole line on the clipboard.
• Cut of a word → Copied 1 line • 3 characters, text removed, undo restores it.

One gap, filed as #347 and Ready: the pbcopy fallback runs with whatever locale TuiCode inherited. With no UTF-8 locale set, pbcopy stores — as — and pbpaste hands the same bytes back, so the check passes and says Copied over garbled text. Leaving #210 in Building until that lands.

Not tried: multi-caret copy live (covered by tests), and the failure message, which needs a clipboard that refuses. Worth trying Ctrl+A/Cmd+C on a large file in iTerm2 yourself, since that's where the original bug hit and slice 3 hinges on whether it still does.

[a-team-app]

Validation: all three tasks merged (#318 → #322, #319 → #339, #347 → #353). Tried on origin/main c13a477. The build is clean and all 1,960 tests pass.

I ran it in tmux with an empty HOME:

• Ctrl+A, Ctrl+C on CONTRIBUTING.md (the original report): the status bar showed Copied 95 lines • 6,341 characters, and the clipboard matched the file byte for byte, — included. The message went back to the file path after a few seconds, and Ln 96, Col 1 (6,341 selected) didn't change.
• Copy with no selection: Copied 1 line • 187 characters, and the clipboard held that line.
• Two carets, Shift+End, Ctrl+C on a line with — § é 🎉: Copied 2 lines • 22 characters, and both lines arrived intact.
• Cut at two carets: same message. The text was removed and it was on the clipboard.

Not tried by hand: the Copy failed: … line and the fallback to pbcopy. On this Mac the built-in clipboard never refuses a copy, so they don't trigger. Unit tests with fakes cover both (#322, #339, #353). Slice 3 (own the clipboard) isn't needed: large copies work.

Worth trying yourself: Cmd+A, Cmd+C on a large file in iTerm2, where this was first reported.

a-team try tuicode