Feature: add clipboard-copy-soft-wrap to preserve visual line breaks on copy

[scottrych]

Feature request: make soft-wrap handling on copy configurable

Summary

When copying a selection that spans soft-wrapped visual rows, Ghostty
collapses the wrapped continuation onto the original logical line, so the
clipboard receives one long line rather than the multiple lines visible on
screen. Other terminals (iTerm2, Warp, Wave) preserve the visual line
breaks on copy, and users coming from any of those expect the same.

A new config option should let users opt into preserving soft-wrap line
breaks on copy.

Repro

1. Open Ghostty and run a command that produces output wider than the
   window, e.g. printf '%s\\n' "$(python3 -c 'print(\"x\"*200)')" or
   seq 1 1 | awk '{for(i=1;i<=30;i++)printf \"%s%s\",$0,OFS;print \"\"}'.
2. The output wraps visually across multiple screen rows.
3. Select the wrapped output and copy (Cmd+C with copy-on-select on,
   or use the selection keybind).
4. Paste into any text editor (Drafts, TextEdit, Notes, etc.).
5. Observed: a single line, no newlines at the wrap points.
6. Expected: a newline at each visual row boundary, matching what was on
   screen.

The same selection in iTerm2, Warp, or Wave pastes as multiple lines.

Root cause

In src/terminal/Screen.zig, Screen.selectionString initializes a
ScreenFormatter with .unwrap = true hard-coded:

var formatter: ScreenFormatter = .init(
    self,
    .{
        .emit = .plain,
        .unwrap = true,    // <-- hard-coded
        .trim = opts.trim,
    },
);

ScreenFormatter already supports unwrap: bool, so all the formatter
plumbing is in place. Only the call site is hard-coded.

Proposed solution

Add a new top-level config option. Following Ghostty's existing
naming for clipboard-content transforms, the prefix should be
clipboard-:

clipboard-copy-soft-wrap = false   # default: keep current behavior

When true, the selection string keeps each visual row as its own line
(newline at every soft-wrap boundary). When false (default), preserve
the current behavior so existing users are unaffected.

Suggested name and shape

• Name: clipboard-copy-soft-wrap. This follows the existing
  clipboard-* family used by clipboard-paste-protection,
  clipboard-paste-bracketed-safe, clipboard-trim-trailing-spaces,
  and clipboard-codepoint-map — all of which transform the content
  that crosses the clipboard boundary. The lone copy-on-select is
  the only copy-* option and refers to the act of copying, not the
  content; a content-transform belongs in the clipboard-* family.
• Type: bool.
• Default: false (preserves current behavior; this is a behavior
  change for some users and a default of false keeps it opt-in).
• Platform: all.

Why not just always preserve visual rows

Some users rely on the current behavior:

• Long JSON blobs, single-line CSV rows, and awk/tr output that
  happens to span many columns are conceptually one record and should
  stay one line on copy.
• git log --oneline, docker ps, etc. already include their own
  newlines; the new option would only affect rows that don't already
  end in \n.

Making it opt-in avoids breaking those workflows.

Sketch of the change

1. In src/config.zig (or wherever the schema lives in the current tree
   — src/config/Config.zig in older revisions), add the field next to
   the other clipboard options:

   /// If true, soft-wrapped visual rows are kept as separate lines
   /// in the copied selection. If false (default), soft-wrapped
   /// continuations are joined with the preceding line, matching
   /// the historical Ghostty behavior.
   copy_soft_wrapped: bool = false,

2. In src/Surface.zig, thread the new field through to the call to
   selectionString. The current call site looks like:

   const str = try self.io.terminal.screens.active.selectionString(alloc, .{
       .sel = link.selection,

   Extend SelectionString (in src/terminal/Screen.zig) to accept
   unwrap: ?bool = null (null = current default), and in
   selectionString do:

   .unwrap = opts.unwrap orelse true,   // false if user opted in

3. Pass the per-surface config value from Surface when it constructs
   the SelectionString opts.

4. Document the option in the config reference
   (https://ghostty.org/docs/config/reference) alongside
   clipboard-paste-protection and clipboard-trim-trailing-spaces.

Documentation

The new option would live in https://ghostty.org/docs/config/reference
next to the other clipboard-* options. To match the existing
prose style (one short imperative sentence, optional clarification, no
heading fluff), a draft entry:

clipboard-copy-soft-wrap

If true, soft-wrapped visual rows are kept as separate lines in
text copied to the clipboard. If false (the default), the wrapped
continuation of each logical line is joined to that line, matching
the historical Ghostty behavior.

Set this to true if you want what you see on screen to match what
you paste. Set it to false (or leave it unset) if you copy output
that is conceptually a single long record — JSON blobs, CSV rows,
git log --oneline lines wider than the window — and want them to
stay on one line.

The existing clipboard-trim-trailing-spaces entry uses a similar
short-prose shape, so the new entry would sit comfortably next to it.

Alternatives considered

• Shorter name like clipboard-soft-wrap or
  clipboard-preserve-wrap. Possible, but clipboard-copy-soft-wrap
  reads more naturally as "soft-wrap behavior when copying to the
  clipboard" and matches the verb in the other option names
  (clipboard-trim-..., clipboard-paste-...).
• Flip the default to true. Rejected: would be a silent behavior
  change for everyone using single-line long output.
• Per-selection modifier (e.g. Cmd+Shift+C copies with line
  breaks). Nice but additive scope; the config flag is the minimum
  useful change. Could be layered on top later.

Environment

• Ghostty 1.3.1 (stable, macOS)
• copy-on-select = clipboard
• clipboard-paste-protection = false
• clipboard-trim-trailing-spaces = false

[scottrych]

A bit of context for anyone landing here directly: I originally opened
this as an issue (#12891), which was auto-closed by the
ghostty-vouch bot per the policy in CONTRIBUTING.md (non-maintainers
should open a discussion first, not an issue). I'm reposting it here
in Feature Requests, Ideas and leaving the closed issue in place as
a pointer.

If the maintainers end up preferring a different option name, default,
or shape, I'm happy to revise — the proposal is a starting point, not
a take-it-or-leave-it.

[bo2themax]

We don't read AI generated discussions, if you don't proofread it yourself before posting, we won't either, and there's a duplicate request already: #12546

https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md#there-are-humans-here