Comment on I don't like the Linux clipboard situation
notabot@lemm.ee 3 days agoI’m still using X11, so this might be different in wayland, but in just about everything shift-insert pastes the selection and ctrl-v pastes the clipboard. In terminals paste from clipboard is ctrl-shift-v as ctrl-v already had a purpose.
Copying to selection just involves highlighting the text, copying to clipboard is ctrl-c or ctrl-shift-c in 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.
PhilipTheBucket@ponder.cat 3 days ago
Well, today I learned something new, that’s pretty useful.
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.
notabot@lemm.ee 2 days ago
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.
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.
PhilipTheBucket@ponder.cat 2 days ago
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.
notabot@lemm.ee 2 days ago
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?