[enriquto]

No word about unix-style clipboard?

Select to copy, middle-click to paste. If I had to highlight an immediate usability advantage of linux with respect to windows and macos, it would be clearly this thing. It feels "at home" when you can do this.

Also, I have a viscerally strong disagreement with the following sentence:

> The majority of the implementations out there are broken and only handle text.

For me, one of the main uses of copy paste is to transform something to plain text. A clipboard implementation that pasted non-text things would be broken.

[imiric]

I don't think having two different clipboard implementations is a usability advantage. Only on Linux do you find yourself in the situation where one application copied to the Unix clipboard, and another tries to paste from the "secondary" (X11?) one. Standardizing on one implementation is the only sane path forward.

[enriquto]

> Only on Linux do you find yourself in the situation where one application copied to the Unix clipboard, and another tries to paste from the "secondary"

This never happens if you only use the unix clipboard. I agree that both methods should point to the same clipboard, but this is an implementation detail. The important thing is the interface: selecting text copies it to the clipboard, middle-clicking pastes it.

[anentropic]

So... selecting some text by accident clears what you previously had in the clipboard?

[enriquto]

Well, of course; why would you want to keep the initial clipboard forever? This is exactly the same behavior as for ^C/^V. I don't understand the purpose of your question.

[rovolo]

> by accident

Imagine you install a 'clapper' in your bedroom to control the lights. You say "works great for me, let's install this everywhere". Someone responsible for an auditorium then says "so clapping turns the lights on and off?"

That said, I frequently use text selection as a highlighter. I will highlight lines as I'm reading text to help me keep track of which line I'm on. I also need to select text to apply formatting such as bold or add link.

[account42]

I have literally never run into applications mixing up the clipboard and selection on Linux - its always CTRL+C->CLIPBOARD->CTRL+V and select->PRIMARY->middleclick.

Super useful to have two different scratch buffers when moving things around.

[wizzwizz4]

Dillo doesn't support Ctrl+C on the contents of websites, so it feels like it mixes them up; actually, it doesn't. (Ninja-edit to correct myself.)

[Someone]

MacOs sort-of has that, too. Control-K and control-Y cut and paste to a separate clipboard (at least in TextEdit.app, with its emacs-like key bindings)

[wodenokoto]

I’m not really sure what middle click has to do with clipboard implementation.

Anyway, I use the clipboard mostly to move images I don’t want to save to a file, so I would hate to have them converted to plain text.

I would also be surprised if I copied a text selection from a website into open office and had to manually redo all the bolds and italics.

[draxil]

For a while a lot of distros started suppressing the Unix clipboard. Not sure if that's still a thing, but drove me crazy because it's just muscle memory for me now.

[ddevault]

Middle click (aka primary selection) is very similar, it's essentially the same interface with a new namespace:

https://wayland.app/protocols/primary-selection-unstable-v1

[bowsamic]

Most people want to copy and paste files and images

[enriquto]

I understand this concern. But it seems that it would be better to have an orthogonal implementation of this. The clipboard remains text-only. If you select an image or a file, it copies its absolute path (or url) into the clipboard. Then it is the responsibility of the destination program to interpret what to do with this text. If you paste the filename of an image into a plain text editor, you'll get the filename verbatim. If you paste it into an image editor, it opens and pastes the image in there. But from the point of view of the clipboard it's always just text (maybe with some textual markers).

[ubercow13]

But I already downloaded the image, I don't want to download it again. What if I want to copy a subsection of an image from an image editor, there is no textual representation as it is not a file on disk.

[NavinF]

That breaks common use cases such as copy-pasting private images that can only be downloaded using your login cookies.

> If you paste the filename of an image into a plain text editor, you'll get the filename verbatim. If you paste it into an image editor, it opens and pastes the image in there

That's how the clipboard already works on Windows as long as the source application provides both formats.

[jakub_jo]

Or better: The data URI gets copied.

[londons_explore]

I find the clipboard increasingly broken for this usecase...

Imagine I want to copy an image from a webpage into an email... And then the paste fails because the email client tries to download the image but doesn't have the correct cookies and fails...

Or I want to copy a file from Google drive onto a USB. But when you copy from the Google drive webUI it just copies the name of the file, not the file itself...

Or I copy an image from Google images and the thumbnail low Res version is copied rather than the full res version.

Copy and paste, and drag and drop, seem to be neglected on the web.

[aasasd]

> I want to copy an image from a webpage into an email... And then the paste fails because the email client tries to download the image.

Personally I haven't had this problem: just like the article says, the browser ‘copies’ image data with a correct mime-type, and the other app pastes the image if it knows about that mime-type. This is on MacOS, with Firefox.

(Though, again personally, I now usually scale the image and convert to webp before sending in a chat—I don't do much email. This way I'm avoiding 4K 4MB pics. I'm probably gonna make me a browser extension to do this automatically.)

You're right however that drag-n-drop doesn't work so smoothly yet.

[Tistron]

I often find myself taking screenshots of pictures for that reason. It's not webp, but also not 4k.

[867-5309]

those are limitations of the browser, not the OS

[londons_explore]

But the user doesn't care whose fault it is. The end result is they get a poor and frustrating experience.

[johnchristopher]

It's the user's fault, though.

If they don't understand the difference between copy pasting HTML with an image inside the tag soup (select with mouse a bunch of text and image and right click copy) and an image (hover image and right click "copy image") then there's not much anybody can do.

Do you want clippy in the browser "looks like you are trying to copy an image" ?

[zzo38computer]

> Select to copy, middle-click to paste.

I also think that this is useful. Furthermore you can have separate selections: primary, secondary, and clipboard.

I use xterm, and shift+insert can also be used to paste from the primary selection. Firefox can copy to primary selection automatically and can paste by middle button, but shift+insert pastes from the clipboard instead; I think that it would be better for shift+insert to paste from primary selection and control+V (or command+V would be better; having that a separate key like Mac OS does is better, I think) for paste from clipboard.

Another thing that is helpful, but many modern programs do not do (some older programs do, such as Heirloom-mailx, and vi) that you can enter shell commands to be used by pipes to transfer data between programs (by use of popen function in C). (Some of my own programs have this capability)

[nicoburns]

I absolutely hate select to copy. It mostly ends up with me overwriting the clipboard unintentionally with data I don’t care about.

I quite like ctrl-c/ctrl-V (or cmd on a mac). Very easy to use while controlling the mouse with the other hand.

[Beltalowda]

> It mostly ends up with me overwriting the clipboard unintentionally with data I don’t care about.

I mostly find it really useful for "quick copies", like the quote from your post here. I don't really care if it gets overwritten because it's only relevant for a few seconds. For anything else you can still use ^C/^V on Linux.

[enriquto]

> you can still use ^C/^V on Linux

How do people stand these particular keybindings? They get so much in the way inside a terminal! They are possibly the worst choice of keys for something as important as copy/paste (if the keyboard is needed at all, but I digress).

^C = forcefully stop the current program

^V = escape to enter the next character verbatim

I use these two all the time, and I find it very confusing that they have a different meaning in other contexts.

[nicoburns]

I use a mac, so it's actually cmd-c and cmd-v for me. And ctrl-c and ctrl-v work in terminals as they normally do. Best of both in my opinion!

[Beltalowda]

I don't use it from my terminal; I just use the select mechanism there. In Vim I have some mappings to copy from and to the + and * registers though.

^V is probably rare enough that it's not a big deal, but ^C is indeed an unfortunate conflict.

[account42]

Clipboard is a GUI thing, terminal emulators are just that - emulators. Not really surprising that there are clashes.

I don't find it too hard to remember to use Ctrl+Shift+C/V in terminals (when I don't just use the primary selection).

[Tistron]

Yes, the Mac is the only system doing this right

[Rutrus]

I used to copy and select, so I copy a URL and select the title of the page, keeping two different memories for pasting.

[fragmede]

The Linux clipboard feels like home to me too, but let's not kid ourselves. Between primary, secondary, and clipboard, it's part of the learning cliff (cos it's steeper than a curve) that is linux. It's totally inscrutable!

ctrl-v and shift-ctrl-v and middle click and shift-middle click and tmux and vim.

The damned system makes no sense! Probably why it feels like home, once you're used to it.