Comment on I don't like the Linux clipboard situation
PhilipTheBucket@ponder.cat 3 days agoBeing 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.
notabot@lemm.ee 2 days ago
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.
PhilipTheBucket@ponder.cat 2 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.