I cannot believe that in this the year of our lord 2025 we still have two separate clipboard buffers on desktop Linux.
There are very few cases where I will execute a paste (whether it is with middle click or Ctrl-V) and I will want the resulting paste to be anything other than the last thing I copied. Whatever X11 subcommittee came up with the idea that users would want to juggle stuff between the two buffers, or whatever the fuck the thinking was, needs to be punished physically. It’s not enough to tell them: They need to remember, so that they will know what they did was wrong, and get fearful in the future if they ever think of doing anything like that again. Their names should be made public, so that people in the future who might want to hire them will know what they did. (I tried to find out who it was, but Google is drunk again and couldn’t really tell me all that much.)
I am already aware that the X11 people spent a lot of time huffing glue in between creating overly complicated standards documents. So maybe the fact that they made some baffling and wrong decisions for literally no reason isn’t surprising. It was a long time ago, a lot of bad things happened back then. What I really cannot understand is why Wayland looked at that decision, and the long history of pain and suffering it had caused over the years, and decided, “You know what? Let’s keep that around. What harm could it do? And anyway… it’s compatible!”
Having two clipboards is literally just worse. Even if we go back to the pre-Wayland days, before the singular clipboard each app chooses to interact with became a mutually incompatible happenstance that depends on the toolkit and historical lineage of that particular tool, so that it’s often simply impossible to copy and paste between two extra tools before you do the standard ritual of installing some “make my clipboard work please” incantations into your system setup that don’t fully work but close enough to stop you complaining, it was still worse. Even back in the X11 days, when all the users just ignored the Ctrl-C clipboard and used the middle-click clipboard, it was still just extra work for no reason. Now, it’s become completely unforgivable. I want to take away these people’s car keys and replace them with a pair of identical keys and tell them that one or the other will randomly work, each morning, and they have to try it and find out, every time. I want to replace one of their morning yogurts with Elmer’s glue, and tell them they should install a Yogurt sync tool if they don’t want the glue, because it’s important to be kind and accommodating to the people who need glue in the morning and that’s what’s important right now.
If anyone knows of something I can run that will just do a simple bidirectional sync between the two clipboards, so I can just pretend to myself that all of this isn’t happening, please tell me. I tried to find a solution for half the morning so far, because I finally just got enraged by it, and I couldn’t find one.
If I imagine hard to myself, I can maybe imagine a scenario where I might want to hit Ctrl-C, then I would accidentally highlight something right after, and then I would want to paste the thing I did Ctrl-C for. But surely that use case isn’t the one that we need to wrap the whole desktop Linux clipboard situation around, to make sure that Fat-Finger Freddy can still get his pasting done, all while the rest of us have to go around saying things like “wl-paste -p -w ‘wl-copy’” and everyone has to do a bunch of extra work whenever they want to do the already difficult task of making pasting work in an editor over SSH or something.
I literally can’t believe how bad it is. It’s like a prank. It’s like one of those imaginary programming languages where someone invented a deliberately malicious feature and then implemented it to a T to be funny.
I do not like it. Not one bit.
Also: Did you know the are three clipboards? The third clipboard is called the “secondary selection,” in keeping with the impeccable human logic that runs all through the X11 codebase like cordyceps through a staggering, dying ant.
Emacs is only editor in history that does anything with the third clipboard. Hold down “alt” and drag with the left button to highlight something, and that thing will go into the special top secret clipboard, where nothing will ever see it.
OH HOW USEFUL
SAID NO ONE EVER
You must log in or # to comment.
I love that there is multiple clipboards, Primary is one of the best things ever. It’s super useful, I often select text in browser while reading and don’t need it in my clipboard, but when there is something interesting copied text is just one click away. Actually I would love a configurable number of clipboards, 5 would be great.
As foryour frustration you can use clipboard manager (iirc klipper on kde syncs them by default but you can disable or enable primary there).
iirc klipper on kde syncs them by default
I wonder why that is lol
I solved my problem already;
wl-pastewas able to set up a situation that’s pretty acceptable to me (which, BTW, actually will preserve your ability to highlight text and then paste something from CLIPBOARD into something else if you want to). Helix over ssh still can only manage to yank text into one of the clipboards, and not the other, but I have invested enough of my free time into this problem at this point and don’t really want to delve into the reasons for that any further since I have a workflow that semi-works and whatever it’s fine.Like I said in one of the other comments, adding the ability to paste text from any of the last N copies would solve your problem as well as many others, and it would also degrade gracefully into acceptable behavior instead of degrading into inability to copy-paste as the current system does. I’ve already solved my problem so I am fine, but I still refuse to accept on any level that this was the right way to structure things.
Ability to paste text from last n copies is also built-in in every clipboard manager, for kde klipper history is mapped to win+v, for others I don’t know.
Ability to sync clipboard over ssh that will support other applications is a neat thing to have, true.
😁 You’re just too late to Wayland. That’s all. Wayland’s lack of primary selection support actually kept me away for years. I like having two clipboards. One with longer lived content and one for immediate use.
Though I’ve now been disabled for quite a while and don’t use a mouse anymore. So I can’t see if there are any bugs.
I recall reading some of the debates on how to specify the support in Wayland and I remember someone bringing up the possibility of having an unlimited number of clipboard and making it the compositor/clipboard manager’s responsibility of juggling that. No idea what became of that.
And actually, if you count dragging and dropping, there are four clipboards.
What’s the logic behind it being better to have multiple clipboards, as opposed to having a single clipboard with accessible history?
I can kind of get how you might want to paste something from a longer-lived conceptual activity even if you highlighted something since then… but if you’re going to do the UI and API work to support multiple sources for the paste, why on earth should it be an arbitrary toolkit-driven decision, with no history, instead of a deliberate decision about which historical copy the user wants to paste out of all the recent copies? What advantage is gained by segregating into separate “clipboards” when we know that the great majority of apps are going to just pick one that’s their favorite and interact with only that one?
Okay, if anyone is curious: I finally lost so much patience with all of this that I fought with it until it was actually doing what I want. It took far longer than it should have.
Here was the secret sauce, for my setup at least:
Wayland needs running in the background:
wl-paste -w sh -c 'wl-copy -p'So what that does is send anything from CLIPBOARD to PRIMARY, so I can click “copy to clipboard” on a web page and still middle-click to paste it. I actually don’t care as much about the other way (which is good because it seems like it might cause an infinite loop); @[email protected] you can rest easy that the Ctrl-V buffer won’t be affected by highlighting text and I can still do paste of whatever I wanted to, even if I highlighted in the middle.
Then in Helix config on any remote machine, have:
[editor] clipboard-provider = "termcode"That’s what enables us to highlight text in Helix and have it make it back to the local system’s clipboard. I actually don’t know which clipboard it’s going into there, and thanks to
wl-paste, I don’t have to care.Then, in kitty config on the local system, have:
mouse_map middle press ungrabbed paste_from_selection mouse_map middle press grabbed paste_from_selection mouse_map middle release ungrabbed discard_event mouse_map middle release grabbed discard_eventThat means that we disable all efforts which Helix will make to grab the middle-click event and fuck it up in some way or other. Kitty pastes the text, Helix receives it, and we have the nice side benefit that it goes in where the cursor is instead of at whatever random position I have let the pointer wander over to before I did the middle click.
Hallelujah. I can get back to actual work. Boy this wasn’t a big extensive confusing waste of time involving extra difficulty that didn’t need to be there. Great. Great.
I’m very happy having the selection and primary clipboards be separate (I’ll admit I don’t use the secondary clipboard). Being able to copy one block, then select a second block, paste that in from selection and then paste from clipboard makes a lot of CLI tasks quicker.
There probably should be a setting that says ‘K.I.S.S just one clipboard please’ though, for those that prefer that way of working.
Being able to copy one block, then select a second block, paste that in from selection and then paste from clipboard makes a lot of CLI tasks quicker.
Which CLI are you using that’s hip to both the middle-click paste and the clipboard paste? What’s an example of a case where being able to hold two things in the buffer at once for pasting them both one after another makes things easier?
It’s not that I don’t believe you, I’m just literally having trouble wrapping my head around how this even happens. I mean, sure, I guess. My issue is I guess much more that there are a lot of tools that only deal with one clipboard or the other, and situations where it is impossible to copy and paste from one thing to another (or was until today) just because of which toolkit one or the other thing is choosing to use. If it was two clipboards that were well-supported from everywhere, and I could always just click “copy to clipboard” in the browser and go to terminal and hit Cmd-V or something to paste it, I wouldn’t be so irritable about it.
I’m still using X11, so this might be different in wayland, but in just about everything
shift-insertpastes the selection andctrl-vpastes the clipboard. In terminals paste from clipboard isctrl-shift-vasctrl-valready had a purpose.Copying to selection just involves highlighting the text, copying to clipboard is
ctrl-corctrl-shift-cin a terminal.I had to actually think about those as they’re basically just muscle memory now! I might use the clipboard to store a path I need to use in multiple places, maybe in multiple tools, and the selection for ephemeral data like a snippet of output from the last command, or an ID value from a web page, something like that. It’s a bit tricky to explain, it’s just the way it’s always worked on unix and linux UIs, and it just becomes second nature to think with those tools.
ctrl-shift-v
ctrl-shift-c
Well, today I learned something new, that’s pretty useful.
I might use the clipboard to store a path I need to use in multiple places, maybe in multiple tools, and the selection for ephemeral data like a snippet of output from the last command, or an ID value from a web page, something like that. It’s a bit tricky to explain, it’s just the way it’s always worked on unix and linux UIs, and it just becomes second nature to think with those tools.
Yeah, I get that. IDK, it’s just bizarre to me. It does make sense. I still maintain that it would make a little more sense, if you’re going to teach all your tools how to use multiple shortcuts and interact with a complex clipboard situation, to do the same thing by just having them able to look back an arbitrary distance in the history of a single clipboard, like M-y in emacs.
if you’re going to teach all your tools how to use multiple shortcuts and interact with a complex clipboard situation
The people writing the tools don’t have to do this, it ‘just works’ as it’s functionality the UI framework provides. It used to be that whether you used Tk, GTK, Qt or any of the others, you still ended up with X11 components on screen, and those components handled the UI interactions like middle click paste from selection or ‘ctrl-v’ paste form clipboard, but then we got a few UIs that tried to draw themselves (Java apps were terrible for this). I don’t know what it’s like on wayland, I suppose it could be different per compositor. I’ll get around to testing it at some point, but I’m in no hurry to leave X11 behind.
just having them able to look back an arbitrary distance in the history of a single clipboard, like M-y in emacs.
You’ll get no argument fro me, that would be a more intuitive approach, although rather than just a stack like that, I’d probably prefer to have a set of registers to yank to and paste from too like vi. That way I can put the information I want to keep using at a specific location, and just use the rolling stack for the more ephemeral stuff.
The people writing the tools don’t have to do this, it ‘just works’ as it’s functionality the UI framework provides.
Read it as “if you’re going to teach all your UI frameworks to do this,” then. My point is, the people who write the software that handles clipboards are having to deal with multiple clipboard. If that’s invisible to the app author because it’s in a toolkit, then great. The people that wrote the toolkit still had to worry about it. To me it would have been preferable if what they’re supporting was a different and more sensible paradigm.
The thing is, in X11 that clipboard behaviour was written once, and that made it work everywhere. Obviously there’ll have been work done on it over time, and non-native frameworks (java UIs and such) would have had to do it themselves, but for the vast majority of programs the author, and indeed the author of the toolkit probably didn’t have to think about it at all. It’s one of the nice things about the X11 architecture that I think we lose with the wayland approach, everything that should work the same everywhere is written once. I suspect that over time we’ll see only a few wayland compositors really lasting and being maintained, and we’ll start to get back to that common architecture.
I can definitely understand your frustration with the clipboard situation, but it’s a decades old paradigm, and I’m used to it, so it seems reasonable to me. That said, I do use clipman to automatically store the text I’ve copied to the clipboard, and let me switch to previous values, so maybe that sort of thing would at least help you a bit?
The thing is, in X11 that clipboard behaviour was written once, and that made it work everywhere.
Dude it just doesn’t work this way. People write apps and they choose keyboard shortcuts, people port applications and frameworks from one place to another. I randomly fired up the first non native program that came to mind, hit ctrl-shift-c, and it didn’t copy stuff to CLIPBOARD. I get what you’re saying but the keyboard shortcuts simply aren’t going to be defined unilaterally by the one and only author of the only allowed windowing toolkit and then everyone’s going to use that for all time. It just doesn’t work that way. Software is a social contract. Actually, I would hold up the MacOS “Ctrl-C versus Cmd-C” paradigm as a golden example of how it should be: The paradigm is clear and easily defined, and obviously makes sense, so of course everyone who’s dealing with some kind of software on Mac is going to adhere to it. It’s easy and sensible, and then the fact that there’s a standard toolkit that provides it out-of-the-box becomes icing on the cake instead of being the only thing holding back dysfunction.
Look at my list of fixes for finally making my clipboard work sort-of the way I wanted it to. Only one of them had anything even vaguely to do with the windowing toolkit. It’s an issue of the fundamental paradigms at work. My complaint was a little bit more focused on X11 introducing a new (and, I would argue, largely pointless) paradigm that now everyone needs to be aware of and adhere to. The people implementing
clipboard-provider = "termcode"in Helix aren’t going to benefit from any X11 toolkit regardless of what software is on the desktop that runs the ssh session connecting to the headless computer where Helix is running. But do they have to think about whether the stuff that gets copied from a remote session is going to go to PRIMARY or CLIPBOARD? Do the people who write the protocol that sends clipboard stuff overxtermterminals? I mean, I would hope they do, otherwise we’re back at the issue of randomly choosing one clipboard or another, which was a big part of what I was saying people would (and did) do in practice and why I levied criticism at the original paradigm for introducing that stupid choice to their programming.I can definitely understand your frustration with the clipboard situation, but it’s a decades old paradigm, and I’m used to it, so it seems reasonable to me.
I mean people said the same thing about slavery. Now that I got it out of my system by whining about it on Lemmy and then took some time to set things up how I want them, I’m pretty much fine with the behavior on my system now. The frustration basically came from (a) things don’t work for me and (b) the reasons why seem stupid, and then coupled up also with © I’m having trouble making it work in a way I am happy with. Now that (a) and © are taken care of by running
wl-paste(which I guess is doing what the xfce person was saying their system does, just on the side instead of out-of-the-box), I’m not embittered about it anymore. But it just still seems silly.Oh, also, update: I found a thing with the new setup that still doesn’t work. Highlighting stuff in Colab doesn’t put it into PRIMARY, and I can’t even really seem to copy into CLIPBOARD since Colab overrides the right-click to offer me a menu that doesn’t give me “Copy” as one of the options.
I mean Colab is shit, that’s not surprising. I just wanted to add one more data point that making a strange paradigm is going to cause issues down the road, whereas simple paradigms have power and can survive.
Edit: Literally right after I sent this message, I needed to copy one thing and then log in to somewhere in order to send it, and I did the thing of highlighting the password in the password manager, middle-clicking to paste it, and then did Ctrl-V to paste the thing I had needed to copy previously and it was more convenient because I didn’t have to go back and copy it again. So yes today it worked out slightly better in that one specific situation.
Just use KDE and you get klipper which is an amazing clipboard manager. It keeps track of everything you’ve copied to your clipboard (raise the history to 999).
Configure it to pop up at the cursor location and whenever you type the keystroke you’ll have access to everything.
I personally prefer that it not paste immediately upon selection but there’s a number of options like that to set it up to your liking.
Just use KDE
Gonna stop you right there 🙂
and you get klipper which is an amazing clipboard manager
Does it sync the select/middle-click clipboard with the Ctrl-C/Ctrl-V clipboard? I do like having both, especially since some tools will only be able to conveniently interact with one or another, it just drives me nuts that they are separate entities. Having a clipboard manager with history is a neat thing but not as essential to me as just having the nuts and bolts working.
I can literally provide you a simple example: Go to https://emojipedia.org/slightly-smiling-face, click “copy”, and then come back and middle click in the reply. Do you get a smiling emoji? If you select some text in the reply and then hit Ctrl-V, do you then get the text you highlighted?
Waow based
Hum, what’s the “second clipboard”? The one where you only highlight a text and then I can paste it with right click?
To me that’s amazing, I can (and do) use ctrl-c for some stuff and highlight for other.
As always, I like the flexibility.
Also I use vi 😜
You should try Helix, it’s vi with some of the odd decisions removed and updated to adapt to some of the evolution (and stupidness, q.v.) that has happened in the Linux ecosystem but still true to a lot of the good stuff that vi does.
I, too, like being able to both middle-click and to hit Ctrl-V. IDK how you got that I was unhappy about that part. What I don’t like is being unable to hit the “copy text” button in my web browser and then do anything at all to get that text into a terminal session, if for some crazy reason I might want to do that. But why, you ask, would I even need to do such a thing? I can always go back, carefully highlight this massive block of text character by character, like some kind of perfectly sensible person, and then carry the text over back to my terminal and middle-click it, like a person carrying an overflowing jug of water through a dance floor. You know what? Forget it, I can’t even remember what I was complaining about.
MacOS, out of all the environments, actually has this worked out perfectly. Not only do they have only a single clipboard, but they have a very consistent set of keyboard shortcuts that supports both a modern and a Unixy workflow. You can use Ctrl-A (go to beginning of line), Ctrl-C (kill program), Ctrl-K, Ctrl-E, all the standard bash/emacs/terminal keyboard editing shortcuts, and they all do what you would expect if you’re a Unix person. But, you can also use Cmd-A (select all), Cmd-C (copy), and so on, and all those shortcuts do exactly what you would expect if you’re a Windows person. Every single program supports all of them consistently, and so it’s pretty easy to get done whatever you would want to get done whatever your accustomed workflow is.
And then there’s Wayland over here like “NOT TODAY MOTHER FUCKER, THAT’S AN EDITOR RUNNING ON A DIFFERENT SERVER, JUST GIVE UP AND TYPE THE PASTE BACK IN BY HAND YOU FUCKING LOSER, YEAH THAT’S RIGHT, DID I STUTTER”
Uhh, so I’ve been on Xfce for a while, and I’ve never seen this. When did the madness start?
You mean into a GUI shell emulator, right? (I didn’t even know there was a clipboard that functions when not in a graphical session, otherwise)
You mean into a GUI shell emulator, right? (I didn’t even know there was a clipboard that functions when not in a graphical session, otherwise)
Correct. Go to https://github.com/LemmyNet/lemmy.git, click on “Code” and then the little “copy please” button next to the address of the .git URL, and then go to a terminal and middle-click. My money is on it not working if you haven’t set up some sort of special mojo for it to work. And, of course, there are things where the amount of text is large and not easy to find the end of quickly among the other boundaries between it and other things on the page…
Nope, that works fine for me. Do you hate this enough to switch?
I mean it works for me now, see my comment where I talked about some of the unreasonably extensive configuration I had to do to make it work the way I wanted. At this point I have CLIPBOARD automatically synced to PRIMARY, so I can always copy something and then middle-click and I’ll get it. And I still have nice behavior that Linux generally makes possible (being able to copy and paste out of terminals even if I’m scrolling around on the thing within the terminal while I’m doing it). Now if someone can just teach Ubuntu what
xterm-kittyas the terminal setting means, when I have to ssh to an Ubuntu machine, I can finally be happy.
