No way to get the sensible whole‐line selection/copying behaviour other terminals have

[emilazy]

When clipboard-trim-trailing-spaces = false, copy‐pasting multiple lines from a terminal includes spaces at the end of those lines to pad them to the terminal width, which is quite bothersome. On the other hand, clipboard-trim-trailing-spaces = true means that you cannot deliberately copy something in the middle of the line with trailing whitespace, or indeed accurately copy an entire line with actual trailing spaces in it (something that the other terminals I’ve used, including Terminal.app, handle correctly).

Relatedly, here’s a screenshot of Ghostty after typing echo 1 and triple‐clicking on the empty space after the end of the line:

and the same in Terminal.app:

You can see here two differences here:

1. Terminal.app considers the newline to span the entire end of the row, in line with many other terminals I’ve used before (though apparently not Kitty or foot); double‐clicking the end of the line selects the “word” that consists solely of this newline, and then the third click selects the entire line. (I personally consider this to feel much more natural, and indeed selecting whole lines in e.g. TextEdit fills up the entire row, although there you cannot select the newline by itself – instead the last word is selected on double‐click and it extends to fill the whole row on the third.)

2. Ghostty does not consider the final space to be selected (even with clipboard-trim-trailing-spaces = false); Terminal.app copies this with one trailing space followed by the newline.

This leads me to suspect that Ghostty’s model does not have a notion of the extent of a line, and instead infers it for selection and copying behaviour by trimming all trailing whitespace. This diverges from other terminals I’ve used, where it has always been very obvious when a tool is behaving unusually by padding out lines with spaces that get copied. If I’m right, I think Ghostty should adopt the model other terminals use, and disable clipboard-trim-trailing-spaces by default or even remove it; the behaviour of Terminal.app, Alacritty, WezTerm, and I think GNOME Terminal and xterm, seems more natural and consistent: you get trailing whitespace if your selection includes trailing whitespace, but lines are terminated by newlines without padding unless such padding is explicitly inserted. It’s possible that there are edge cases here relating to the VT model, but personally I haven’t run into them when using other terminals.

[emilazy]

This leads me to suspect that Ghostty’s model does not have a notion of the extent of a line, and instead infers it for selection and copying behaviour by trimming all trailing whitespace.

I only just now realized that you can select spaces at the end of lines (that in other terminals wouldn’t have any), which indeed suggests that this is true and that Ghostty is hacking around it for things like triple‐clicks and copying in a way that seems unnecessary and suboptimal compared to just addressing it in the underlying model.

[gtirloni]

I routinely have issues copying terminal output from certain commands and pasting them into other places (various text editors, browser textboxes, etc).

Sometimes Ghostty will correctly trim the whitespaces from all lines so when I copy them, they are correctly formatted. Other times it will copy the white spaces AND not add a newline anywhere so it becomes "line1 <-------- whitespace ---------> line2line3" or a combination of that.

The workaround I found was to run reset on the affected terminal and run the command I want the output from again. Sometimes I needed the initial output and running the command again gives me different output which breaks my troubleshooting.

The worst thing about this behavior is that I can't copy/paste long text without inspecting that the pasted text doesn't have issues, line by line, which erodes trust in Ghostty.

I've switched to using the tip version but the issue persists.

[mattboston]

I have the same issue. I'll try the reset method to see if that helps, but that's not really a fix since a lot of times I have a long running terminal session.

[cmlad]

The issue seems to be that HTML copy format doesn't include breaks, but white-space: pre;:

To repro run in Ghostty:

echo 2

Copy the result:

$ echo 2
2

Ghostty writes to clipboard in a few formats:

$ osascript -e 'clipboard info'
«class utf8», 10, «class HTML», 71, «class ut16», 22, string, 10, Unicode text, 20

Check UTF-8 clipboard - it's correct:

$ pbpaste | xxd
00000000: 2420 6563 686f 2032 0a32                 $ echo 2.2

However, check HTML clipboard:

$ osascript -e 'the clipboard as «class HTML»' 2>/dev/null | sed 's/«data HTML//;s/»//' | xxd -r -p
<div style="font-family: monospace; white-space: pre;">$ echo 2
2</div>

There is no <br> so many apps that prefer the HTML version (e.g. Claude Code) paste as:

$ echo 2 2

For comparison, iTerm2 doesn't even bother with HTML:

$ osascript -e 'clipboard info'
«class utf8», 10, «class ut16», 22, string, 10, Unicode text, 20

There is a separate issue with extra new lines when copying long lines with formatting, but the repro is not easy.

[jby]

See my comment in #12842