Idiomatic paste behavior in Linux

[mohshami]

In Linux, terminal emulators have the following behavior

Middle-click always pastes from the PRIMARY/SELECTION clipboard.
Paste action (Normally ctrl+shift+V) always pastes from CLIPBOARD.

This behavior persists regardless of the copy-on-select option (for those terminal emulators that support it)

That behavior was added to Ghostty in #2347, along with the documentation below

# Whether to automatically copy selected text to the clipboard. `true`
# will prefer to copy to the selection clipboard, otherwise it will copy to
# the system clipboard.
#
# The value `clipboard` will always copy text to the selection clipboard
# as well as the system clipboard.
#
# Middle-click paste will always use the selection clipboard. Middle-click
# paste is always enabled even if this is `false`.
#
# The default value is true on Linux and macOS.
copy-on-select = true

#12443 broke that, making Ghostty behave differently from all other emulators on Linux.

I am not sure how terminal emulators behave in MacOS, I think #12443 should be limited to MacOS or a 4th option needs to be added to copy-on-select to modify CLIPBOARD but keep middle click paste from SELECTION.

Since #12443 is scheduled for 1.4, I think more people will see the difference once that out

I can't stress enough how much I appreciate the colossal amount of work everyone is putting. Thank you all

[007hacky007]

I think the premise here is incorrect.

#12443 did not break the standard Linux terminal behavior. With:

copy-on-select = true

Ghostty behaves like the standard Linux/X selection model:

• selecting text writes PRIMARY
• middle-click pastes PRIMARY
• explicit copy writes CLIPBOARD
• Ctrl+Shift+V / explicit paste reads CLIPBOARD

That is the standard behavior.

The behavior being requested here is different:

• selecting text writes both PRIMARY and CLIPBOARD
• middle-click still pastes PRIMARY
• Ctrl+Shift+V pastes CLIPBOARD

That may be useful, and it may match some terminals when they enable an extra “copy selection to clipboard” convenience option, but it is not the standard Linux/X clipboard model.

So I don’t think #12443 should be reverted or limited to macOS. It makes copy-on-select = clipboard internally consistent: if selection is copied to the regular clipboard, middle-click follows that same clipboard choice.

If users want the older hybrid Ghostty behavior, I think that should be discussed as a separate extra mode, something like “copy selection to both clipboards, but keep middle-click on PRIMARY.” But that should be treated as a compatibility/convenience option, not as the standard Linux behavior.

Also original discussion is here and it seems like more users agree with the merged behavior.

[mohshami]

Sorry, didn't mean to say it broke Linux behavior, I meant to say it broke Ghostty's original behavior that was idiomatic with Linux.

[007hacky007]

No it does not break Linux behavior just set copy-on-select = true that mimics Linux standard behavior.

[mohshami]

Sorry if I was not clear, the issue is

copy-on-select = clipboard

selecting text writes both PRIMARY and CLIPBOARD
middle-click pastes CLIPBOARD <- This is what breaks Linux/X behavior

[rhodes-b]

putting a thumbs down on every comment from them and saying copy-on-select = clipboard needs to stay how it is now (not the previous) is very opinionated behavior.

middle click pasting from selection is the idomatic linux behavior regardless of if copy also copies to the system clipboard, copy and pasting are 2 separate actions so from that perspective copy-on-select = clipboard absolutely does not have idomatic paste behavior on linux as its pasting the system clipboard.

[007hacky007]

Again. Just use copy-on-select = true to mimic standard Linux behavior. What @mohshami wants may be useful but it is not standard Linux behavior. And that's the hill I'm going to die on.

[mohshami]

Regardless of the copy-on-select value, in Linux, pressing the middle mouse button should paste SELECTION, making it paste CLIPBOARD is not standard behavior. While copy is fine, paste is what is now different from the normal Linux behavior

[rhodes-b]

Again. Just use copy-on-select = true to mimic standard Linux behavior. What @mohshami wants may be useful but it is not standard Linux behavior. And that's the hill I'm going to die on.

You can die on that hill but copying and pasting are 2 separate actions

[007hacky007]

@mohshami again just use copy-on-select = true and you'll get standard Linux behavior. It will paste with middle mouse button.

Also author of Ghostty is using Mac. And on Mac pasting clipboard with middle mouse button is standard.

[jcollie]

This conversation is getting a little heated. Going to lock it for a while to let people's egos cool off.

[jcollie]

Unlocked. Please keep things productive!

[mohshami]

Thank you @jcollie

Just a final thought on the subject. I do understand the intent behind the patch. But as we thrive for a native experience on all supported operating systems (Now MacOS and Linux), we need to reconsider.

On Linux, all apps (terminals as well as browsers, text editors, ... etc) paste from SELECTION when the middle mouse button is clicked. Changing a "copy" option should not change a "paste" behavior.

There are a considerable number of people who want copy to be to both SELECTION and PRIMARY, which is why many terminal emulators have that option to begin with. On those emulators, enabling that option doesn't affect the paste behavior.

I would appreciate we reconsider how #12443 is implemented, it needs to be a separate option and not force users to choose between copy-on-select to PRIMARY and pasting from SELECTION on middle click.

Thanks again for all the effort everyone has been putting into this amazing piece of software

[00-kat]

On Linux, all apps (terminals as well as browsers, text editors, ... etc) paste from SELECTION when the middle mouse button is clicked. Changing a "copy" option should not change a "paste" behavior.

My opinion is that there's two ways one could interpret this:

1. Middle-click follows that of selection.
2. Middle-click always pastes from PRIMARY.

n.b.: as far as I know, SELECTION isn't a thing; “selection” instead refers to either PRIMARY, CLIPBOARD, or the other obsolete ones.

Per the default X model, selecting is meant to copy to PRIMARY, so both options unambiguously result in middle-click pasting from PRIMARY; however, if one changes that to instead copy to CLIPBOARD, it's no longer clearly defined what middle-click is meant to do. The person who made that change believes it should be (1), while you believe it should be (2).

Re one of your older comments:

copy-on-select = clipboard

selecting text writes both PRIMARY and CLIPBOARD
middle-click pastes CLIPBOARD <- This is what breaks Linux/X behavior

This is indeed what it's documented to do, but this makes no sense to me: the clipboard usually isn't also considered to be PRIMARY. And besides, it makes (1) from above itself ambiguous: it's not obvious what “following that of selection” means given it copies to both.

Both @jcollie and I believe that this should be configurable, since the current way is confusing, completely arbitrary, and non-standard anyway (since selecting isn't meant to copy to CLIPBOARD per X). jcollie suggested:

• copy-on-select should allow off, primary, clipboard, or both, with clipboard only touching CLIPBOARD while leaving PRIMARY untouched;
• middle-click-action should be extended to allow selecting which cut buffer middle-click pastes from.

Of course, jcollie is the GTK maintainer here (well, and Tristan), not me, and I don't want to put words into his mouth; I'm simply recounting the discussion that happened in a private Discord channel a little bit after you brought it up again in #development, and jcollie is the one who can promote this discussion to an issue.

[jcollie]

#12600

[jcollie]

I don't know zig but I am comfortable with writing code, can I have an AI assisted PR?

Be sure to read all of our guidelines. You can use AI assistance, but you (the human) must be able to understand the code and be able to answer questions and respond to reviews of the PR without AI assistance.

[jcollie]

Also, don't use AI to write code for platforms that you can't personally test.

[mohshami]

I am so terribly sorry, got the names confused there.

#12600 solves the issue. Thank you @jcollie

[jcollie]

#12600