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.