The universality of copy/paste is overrated.
It's literally just adding shift in terminal emulators, no biggie.
A bigger UX problem (on Linux) imo is the multitude of clipboards, we have x11, vim... Those can be synchronized or not, they manifest different behaviors...
And btw while apple is often offered as some golden standard for key bindings, I think the situation there is much (MUCH) worse: apps often intercept and handle common combinations on their own, with unclear precedence, which leads to non-deterministic behavior and a complete mess if you want to override any standard combination.
Wilder7977 6 hours ago [-]
> And btw while apple is often offered as some golden standard for key bindings, I think the situation there is much (MUCH) worse: apps often intercept and handle common combinations on their own, with unclear precedence, which leads to non-deterministic behavior and a complete mess if you want to override any standard combination.
Thank you. That is absolutely the case. As someone who had to switch to Mac for work, I found the keybinding situation to be a complete mess. It's also incredibly hard to track down and change certain keybindings, many apps don't have any text configuration to easily modify and require you to go through their GUIs which require you to know what you are looking for (e.g., which app).
troupo 3 hours ago [-]
> I found the keybinding situation to be a complete mess.
As in: most shortcts work the same across all apps?
> It's also incredibly hard to track down and change certain keybindings, many apps don't have any text configuration to easily modify and require you to go through their GUIs
An important lesson to learn is the way X11 does copy/paste (hint: it doesn't).
You select (typically via the mouse) something on the screen. The client (the software that handles this, e.g.terminal emulator, browser, office editing suite) declares ownership on a "selection". There are at least 3 of them: PRIMARY, SECONDARY, and CLIPBOARD.
Nothing gets copied!
When you go to some other client (or even the same) and do a "paste", a request is sent to the first client (the selection owner), "please give me the content". The second client gets the content and does whatever it wants with it, typically inserting it somewhere.
Contrast this way of operation to what other systems (like Windows and Mac) do: the content is copied to a central place, and then copied out to be "pasted". If one wants this behavior in X11, one needs to run something like a "clipboard manager" which can trivially implement this. I must admit, when using Windows, instead of Ctrl-V for pasting, I have completely switched to Windows-V, which gives you at least a history of the copied content.
Going further, on X11, the additional wonderful part is that there are also content-negotiation primitives built-in in this exchange!
So it could be the case that you select some formatted text in your browser, you want to paste it in your text editor (e.g. gvim), the editor asks ("give me the content, in Markdown (or HTML) format") and this is what gets transferred and eventually inserted.
Or, if you select an image, you can paste the SVG text that generated it.
I have no idea what Wayland does, but this is another functionality that is extremely helpful and will be missed if not available, when/if X11 is replaced.
account42 15 minutes ago [-]
> Contrast this way of operation to what other systems (like Windows and Mac) do: the content is copied to a central place, and then copied out to be "pasted".
This is a gross oversimplification to how Windows manages the clipboard. In the general case, the situation is not much different from X11 and the data stays in the sending application until requested - and is lost on program exit.
yjftsjthsd-h 6 hours ago [-]
> A bigger UX problem (on Linux) imo is the multitude of clipboards, we have x11, vim... Those can be synchronized or not, they manifest different behaviors...
I would probably like vim's + register to always sync with the X/Wayland clipboard where possible², but it is perhaps worth pointing out that vim has (at least?¹) 28 "clipboard" slots (+, *, a-z) and this is a feature not a bug. Having accepted that, I would likewise point out that X having a clipboard and selection buffer is an intentional feature. I'd support universally supporting one single shared clipboard that everything uses properly by default, but I wouldn't want to limit the other options to do it.
²Edit: Oh, yes, I do agree that I would be in favor of making that the default register as well so that ex. just `yy`/`p` used it.
koiueo 6 hours ago [-]
> supporting one single shared clipboard that everything uses properly by defaul
Agree. I got to realize how convenient it is to have one shared clipboard by default after I tried (doom)emacs: behaves like vim, has registers like vim, but default register uses the clipboard. I can still use all the registers as much as I like, but the default one is global and can be shared between apps.
I now configure my vim like this.
I still miss this, however, when working occasionally without a graphical session. Perhaps there's a solution, but I haven't yet bothered to look for it.
NDxTreme 3 hours ago [-]
It should be included in the :OS section, the tty defaults. From the docs.
"This module configures Emacs for use in the terminal, by providing:
System clipboard integration (through an external clipboard program or OSC-52 escape codes in supported terminals).
Cursor-shape changing across evil states (requires a terminal that supports it).
Mouse support in the terminal."
lucideer 6 hours ago [-]
> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.
I used to think this before I got a job in a Mac-only company. I've since installed Toshy on every Linux machine I own & the difference is night & day. Having to do something extra for terminals to achieve the thing that's so simple & natural (& frequent) in GUIs just feels like terminal emulators are being treated like second class citizens among the installed apps. Having the same shortcuts "Just Work" in exactly the same way through all apps isn't just more convenient, it feels like the OS is elevating terminals to an equal tier of integration.
Which I would've really expected more Linux users would value more than they seem to.
JoshTriplett 6 hours ago [-]
I learned Ctrl-C for "kill program" very nearly before Ctrl-C for copy existed, and long before it existed on any platform I used. I value consistency, but I also value consistency with common practice for the type of application I'm using.
The common failure mode, for me, isn't hitting Ctrl-C for copy in a terminal by mistake, it's hitting Ctrl-Shift-C for copy in a browser and ending up with the console open, or hitting Ctrl-W to delete a word and having it close a tab.
Svip 3 hours ago [-]
Kind of wish Firefox allowed one to modify the common keyboard shortcuts in the browser. But considering the open issue on the matter, I won't keep my hopes up: https://bugzilla.mozilla.org/show_bug.cgi?id=57805
The hacks about seems to be basically steal keyboard shortcuts the same way webpages already do; either through an extension[0] or modifying config-pref.js[1]. Neither of which seems very appealing to me. Though, funnily: I did hit Ctrl-W writing this message to delete a word; thank goodness for cache.
This drives me nuts as well, the number of times I close a tab with C-W, or select all with C-A...
My brain can "switch mode" when on a regular web page, but if I open some kind of "terminal in a page" (i.e. I the AWS console), then I'm 100% it will end up with a C-W.
JoshTriplett 5 hours ago [-]
For me, it happens most often when I have a call open in a browser in one window, and a terminal open on the other half of the screen taking notes, and then switch to the call and start typing something in the chat.
koiueo 5 hours ago [-]
I'd say Ctrl+W is just a terrible shortcut for closing a tab.
It's right near Ctrl+Q, which usually quits an application.
While Q is mnemonic, W is not.
It's too ergonomic and requires very little wrist movement for such a destructive action.
I understand your pain, but I blame the author of this weird convention for the "close tab" action, whoever they are
franga2000 4 hours ago [-]
What exactly does Toshy do for you? The readme is incomprehensible...
For the specific case of copy-paste in a terminal, you either have to press something extra for paste or something extra for SIGINT - there is no secret third option. You could remap copy (bad for muscle memory) or remap sigint (similarly bad for muscle memory, but also confusing since many terminal apps mention CTRL+C explicitly).
I guess a better place for copy/paste would be WIN+C/V, since it feels like a global function and not an app-specific one, but the way clipboard is implemented makes it an app shortcut by necessity. This convention also doesn't hold with things like ALT+TAB (switch windows) and CTRL+Q (close window), both of which feel like "system" shortcuts but don't use WIN.
So I guess my point is...keybinds are already a mess "because legacy" and any attempt at solving that mess would just result in less universality and worse muscle memory, which goes against their whole reason for existing.
In the grand scheme of things, "when in a terminal, press shift to escape key combos" is a very easy convention to get used to. Also work for mouse integration, for example if you have vim open and mouse integration enabled, but want to select and copy using the system clipboard.
lucideer 2 hours ago [-]
Toshy makes Cmd-C copy in all Linux apps: both GUIs & Terminals. This avoids any clashes with Ctrl in terminal as you're using Cmd for shortcuts everywhere instead.
> there is no secret third option
I assume you're thinking of trying to use Ctrl-C in terminals? The secret third option is never using Ctrl at all outside of terminals.
> I guess a better place for copy/paste would be WIN+C/V
Yeah that would likely be the equivalent of Cmd if you're using a Windows keyboard. That is how it's configured across all apps by default in macOS & Toshy just ports that sensibility over to Linux.
In Windows Terminal CTRL+C is copy if there is a selection and interrupt otherwise. It's very natural.
Flockster 16 minutes ago [-]
You can do this with many terminal emulators on linux too. I did it with konsole and tilix, just change the copy and paste shortcut and you get this "natural copy" behavior.
doix 6 hours ago [-]
I have the exact opposite problem on a Mac. Things don't just work. You can select text in the terminal and then middle click to paste it. But that only works in the terminal, not anywhere else.
Catches me out a bunch. There is also only a single copy buffer, so to copy from the terminal and paste into a browser I need to replace what was in my clipboard, drives me insane.
> Which I would've really expected more Linux users would value more than they seem to.
Because you get used to it and then don't think about it. I value having two copy buffers over consistency for the sake of consistency.
lucideer 2 hours ago [-]
> You can select text in the terminal and then middle click to paste it. But that only works in the terminal, not anywhere else.
I guess this is likely an odd affordance to unix norms rather than a planned/intended shortcut (I've never tried it & never knew it worked anywhere). I'm not much of a mouse user in terminals though so I guess it would just be a little less natural.
trinix912 6 hours ago [-]
A clipboard manager solves all of this and doesn't break the consistency and expectation that the same shortcut copies/pastes to/from the same place.
doix 4 hours ago [-]
Which one do you recommend? I tried multiple when switching, but none of them quite worked right. I want:
* Two seperate buffers
* Separate shortcuts to paste them
* Selecting text _anywhere_ automatically puts it into the second buffer
I couldn't find anything that did this, so I just gave up and deal with it on my work laptop (and occasionally whine about it on HN when it comes up)
pinoy420 6 hours ago [-]
Command c command v works fine for me because I don’t “optimise” my experience.
It’s a fun game to do I guess but if you become “more productive” by having a slightly quicker mechanism to find a file through 9 different chords on your terminal only interface - you likely aren’t solving problems that are worthwhile.
doix 4 hours ago [-]
I've heard this opinion worded slightly different many, many times over the years. I just can't agree with it. You're going to spend thousands of hours infront of a computer, it makes sense to invest time in being "efficient".
You reach a point of diminishing returns with everything. You can only gain so much knowledge/intelligence/experience before every increase in that becomes extremely difficult. Trying to become "smarter" when you are already "smart" is much harder than getting easy efficiency wins.
There are people that take it to the extreme of course, where they spend all their time on extremely tiny efficiency wins instead of learning how to program, but that's the same problem in reverse.
It's a pretty old concept, the first time I've seen it given a proper name was "aggregation of marginal gains" [0].
Also Emacs keybindings. Being able to use your text editor muscle memory for editing in every text field of every native app is fantastic.
Tor3 4 hours ago [-]
My muscle memory automatically uses Emacs keybindings for this, in editors like Pluma.. and the whole buffer is gone. Fortunately there's an "undo" option. But I really want Emacs keybindings to work everywhere. I have my various shells set that way.
koiueo 6 hours ago [-]
> every native app
That's a very big fineprint.
With three most popular apps among developers being (I imagine) browser, jetbrains ides and vs code derivatives, all being non-native, muscle memory becomes pretty unreliable.
But yeah, would be big, if it indeed was universally supported
adastra22 4 hours ago [-]
I use SIGINT more frequently in a terminal than copy-paste. I suspect this is also true of most power users. That’s why the situation is the way it is.
lucideer 2 hours ago [-]
I don't think you understand - macOS prioritises SIGINT use by introducing a new keyboard key for copy/paste instead of masking Ctrl. Using SIGINT more frequently is exactly the point.
miohtama 6 hours ago [-]
> Which I would've really expected more Linux users would value more than they seem to.
It's likely that the users who find this annoying will simply stop using Linux.
bigstrat2003 5 hours ago [-]
I find it annoying, it just.. is what it is, you know? Not like other OS choices don't come with their own annoyances, so I have to choose whichever warts I can live with. Right now, that's Linux.
eviks 6 hours ago [-]
> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.
It's literraly breaking your muscle memory for one of the most commonly used shortcuts for no reason. It's a pretty big ergonomic blunder
klabb3 6 hours ago [-]
It should be physical keys and they should be the same on every platform. I have at least 20 keys on my desktop keyboard that I never use, it’s not like the real estate isn’t there. Many older non-technical people struggle with combination keys.
If we had physical keys, we could also fairly easily add multiple clipboards like Copy+2 or Copy+F2 could be clipboard #2 without impacting the basic ease of use.
eviks 5 hours ago [-]
> physical keys and they should be the same on every platform.
That's an easy no, precisely because
> have at least 20 keys on my desktop keyboard that I never use
Very common operations should be ergonomic, i.e. have a convenient location. Unless you mean to make all keyboards split ergonomic with a thumb cluster, so you'd have prime space for copy and paste, adding bad 21st and 22nd key far away will be worse than a more convenient modifier
Also, you forgot laptops where there is not enough real estate to even fit the full standard desktop keyboard
(multiple clipboards would be a great benefit, though)
klabb3 3 hours ago [-]
Status quo bias? First we have a large caps lock key and two alt keys. And we even have a ”Windows key” (probably soon an annoying AI key?). Many languages have additional keys, even on laptops (eg Swedish keyboards have å, ä and ö in addition to English ascii) so the real estate argument feels surmountable. Muscle memory and having to retrain is the real issue - you only want big changes like that at most once per decade or two.
> adding bad 21st and 22nd key far away will be worse than a more convenient modifier
Even if in the scroll lock/pause-break region it would help a lot for those who struggle with modifier keys. With this option you could keep Ctrl+C/V.
eviks 2 hours ago [-]
> Swedish keyboards have å, ä and ö in addition to English ascii
That counts against you because now you have even fewer keys to work with to add copy/paste, shouldn't that extra physical key be instead used for those extra useful letters?
> First we have a large caps lock key and two alt keys.
My "Status quo" is using them for other better things. And right alt is also currently use for those non-ascii Europeans, so that's not an easy win. Caps lock might be, the current default is a disgraceful waste. So that only leaves Paste
> Even if in the scroll lock/pause-break region
Again, you don't have it on laptops, that's the main source of space constraints, so now you don't have universal muscle memory experience.
> With this option you could keep Ctrl+C/V
Hm, yeah, I thought of a universal replacement.
Podrod 1 hours ago [-]
[dead]
audiodude 5 hours ago [-]
Isn't this what TFA suggests?
XorNot 5 hours ago [-]
Lower on my priority list then separating out linguistic space from list space.
In the shell I want the super key or tab or something to mean "new list item" - no more escaping spaces (this will of course never happen in my lifetime - but if you're rebuilding technology post apocalypse with a clean slate...)
audiodude 6 hours ago [-]
All day in ChromeOS at work it's accidentally open the dev tools in chrome (you Ctrl-Shift-C'd when you should have just Ctrl-C'd) or kill my server in the terminal (opposite direction). All. Day.
grues-dinner 5 hours ago [-]
Same in Firefox. Absolutely infuriating and trivial for them to fix/disable with an about:config even if you absolutely had to keep Ctrl-Shift-C for the masses. I suppose it only affects, oh, everyone in the world who uses both dev tools and a terminal. Which is almost a complete intersection with people who use dev tools! Or have they always been expecting AI to take over web design entirely and you no longer need terminals or something?
You can inject JS into every single page to fix it via an extension, but extensions don't have the ability to fix it otherwise. I suppose you could also intercept it in an IME?
zajio1am 23 minutes ago [-]
> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.
You have to know what to add. Sometimes it is shift, sometimes (rxvt) it is alt.
incompatible 6 hours ago [-]
I don't even like the solution. "Buy a new programmable keyboard." The keyboard I've got generally works fine. It's not programmable as far as I know, but who knows for sure.
The clipboard has always been annoying. Even today, you often see a "copy to clipboard" or something on a web page, and it never works on Linux. Not as I've got it configured, in any case.
account42 6 minutes ago [-]
With X11 you don't even need a programmable keyboard for this, just make your own xkb layout. These support multiple layers just fine.
lucumo 5 hours ago [-]
> Even today, you often see a "copy to clipboard" or something on a web page, and it never works on Linux. Not as I've got it configured, in any case.
That's weird. It's a pretty widely available Javascript API for years already. Nothing OS specific on the website's side. Are you running an ancient/fringe browser?
Sure, but the API is primitive and limited. The browser puts it in CLIPBOARD, but then the user pastes from PRIMARY and gets something they didn’t expect. And the author of the web page probably included some event handler(s) that breaks the selection, so that selecting text doesn’t copy to PRIMARY like it should either.
incompatible 3 hours ago [-]
I suppose something like that is going on. Perhaps if I use some kind of "clipboard app" I'll be able to recover it.
Edit: Hmm, got one already called clipman, and it can display the two types of selections, now just have to figure out how to use it.
graemep 1 hours ago [-]
My biggest annoyance by far is that select on multiple browsers location bar does let you middle click paste the selection. You have to copy and paste.
It's an inversion. Instead of the user selecting and then having to figure things out, they declare an "intention to paste" and then do the selection.
In practical terms, they invoke the "use clipboard" feature then the code probes all the clipboards (tmux/primary/emacs/nvim/clipboard/secondary) and the user selects their text. One (or more) changes. That's the clipboard it's going to use.
johnisgood 6 hours ago [-]
I love the multitude of clipboards.
I love the fact I can select from the terminal, or from the GUI, and I can use Shift + Insert or middle click.
I love how I can have another clipboard using Ctrl-C / Ctrl-V.
I use both on an everyday basis and has been for almost two decades.
zajio1am 26 minutes ago [-]
I like having bot selection and clipboard, but problem is consistency. In terminal (rxvt) shift-ins pastes selection, while in GTK app, the same shortcut pastes clipboard.
GTP 4 hours ago [-]
I also think on Linux it's just a matter of pressing shift in terminals, but I also ended up opening an unwanted developer tools window in Firefox countless times while copying strings between the browser and the terminal due to ending up using the shift inside Firefox as well. Not a dealbreaker, but annoying.
lucketone 2 hours ago [-]
Ctrl ins/shit ins.
(Not the home row, but no accidents with it)
ArtRichards 2 hours ago [-]
came here to post this,
but it shares a different clipboard than ctrl+c/v or something??
anyone know the differences?
AlecSchueler 4 hours ago [-]
> A bigger UX problem (on Linux) imo is the multitude of clipboards, we have x11, vim... Those can be synchronized or not, they manifest different behaviors
It's funny though because I'm so used to it I actually have it as part of my workflow and use the different clipboards differently. If I have to use a non-Linux machine for a while I suddenly feel crippled by only having the one.
cycomanic 5 hours ago [-]
I almost exclusively use middle click paste when dealing with the terminal (and most other things as I find it much more convenient).
That actually has become more annoying recently, because it seems to work very inconsistently in browsers now. Somehow some websites (e.g. The code blocks in webui, GitHub...) seem to not use the regular clipboard selection so pasting from that doesn't work (I hadnt had time to really investigate)
savolai 6 hours ago [-]
With all kindness: Compared to mac/ios, android and linux and windows ux is death by thousand papercuts. (I’m not saying apple is perfect either, and maybe we have landed in a digital experience world that is broken for nearly everyone anyway, but I digress. :)
I am already cognitively burdened. I do not need developers telling me at what point the cumulative inconsistencies become a biggie. Copy-paste is a common action and each inconsistency I need to learn is away from my core tasks and ability to focus on those is already scarce as f.
Devs do not get to decide how central a terminal is to my workflow, and whether that terminal app deserves to have the right to tell me that it’s now a special butterfly I need to accommodate my cognition for.
But I guess Linux desktop has chosen its path of being only for tinkerers who are prepared to adopt an entire culture of quirks instead of users focusing on what’s important for them in their own lives.
I’m disappointed this still does not fix the core issue of this being broken for everyone by default.
Wilder7977 5 hours ago [-]
> Devs do not get to decide
In my experience Apple devs are the _most_ opionated in terms of telling users how they should use their machine. The UI controls are super touchpad-centric, and it's crazy that a community-driven project like i3 is light years ahead to macOS "wm" features (not to talk about the native UI management). Also they decide for you where the icons to close the windows are, you want to change them? Nope, sorry, you are doing it wrong and can't move them.
Your keyboard? Also wrong, you should buy an apple one, otherwise your modifiers are all messed up. You don't use the application docking bar? Well, you are doing it wrong, you can reduce it, but can't remove it, it's always going to be there at the bottom.
There are countless of instances in which the only way to do something is the Apple way, so much so that everyone who switched from Linux to Mac I have spoken with essentially concluded that either you bend to how Apple decided things should be done, or you will be constantly fighting your own machine.
I appreciate that this means that if you start with Apple and get used to their way, you have no cognitive burden on how to do something, but when you use your machine every day, you want to decide how things work to reduce your cognitive load (I.e., this is more intuitive for me this way), and Apple really doesn't like that.
trinix912 5 hours ago [-]
I think he meant devs of 3rd party software, not devs of the OS.
JoshTriplett 5 hours ago [-]
> Compared to mac/ios, android and linux and windows ux is death by thousand papercuts
"What you're used to" is a major component of usability. I've had to do short stints on a macOS machine before, and find it a painful experience that I'm happy to be rid of when I'm done. People who are used to a macOS machine sometimes say the same thing about a Linux machine. They can both be right at the same time.
It isn't the only component of usability, to be clear, and it's also possible for applications to be objectively better. But familiarity and usability are often conflated.
alkonaut 5 hours ago [-]
Windows UX has many warts too, but the idea of a single system clipboard where I can copy paste between a console and a web browser in either direction using the same shortcuts in both, seems like a really low bar for an acceptable clipboard UX.
atoav 6 hours ago [-]
I use KDE as a daily driver at work, privately run windows 12 and maintain six modern macs at my workshop. Of the bunch KDE is easily the best, with the least amount of weird unexpected behavior and the most logical, user-centric way to lay out and present system setting. Windows 11 feels like an archeogical research trip into the UI paradigms of the past every time you need to change the settings, and macOS constantly does things you didn't ask it for and disallows/breaks things you did for the past years. And there are small things like: After every software update I have to manually put shortcuts into the dock again on six computers. They make it harder and harder to run software that hasn't been approved by apple. And the small UI papercuts are easily worse than on KDE (I count here stuff that clearly didn't work as intended, not stuff I have opinions about).
atoav 4 hours ago [-]
Correction: Windows 11, that was a typo, sorry.
koiueo 6 hours ago [-]
I have home key on my external keyboard. While home in combination with any modifiers behaves consistently under Linux, it's an utter mess under macOS. Sometimes my cursor jumps to the beginning of the visual line, other times to the nearest \n before the cursor, sometimes when no text editing is involved, it scrolls the frame, other times it does nothing.
First time I tried macOS I was impressed with the globally (so I thought) respected emacs bindings (^E, ^A, and especially ^N and ^P). But then I have painfully discovered that almost every(?) app just mimics the default scheme, but essentially implements its own handling, which leads to numerous inconsistencies spreading way beyond copy/paste. That's when I realized why most macOS users I've observed use touchpad to manipulate cursor during text editing – there's no reliable universally consistent way of doing this under macOS
macOS is not just "not ideal". It's as messy as other OSes, but with its own bag of unique warts.
But I understand it's easy to ignore them once you get used to them.
matheusmoreira 5 hours ago [-]
With all possible kindness...
> Devs do not get to decide
I'm sorry but developers get to decide literally everything. They're the ones putting in the work. They build the systems they want for themselves. They solve the problems they personally care about in ways they personally feel is best.
If you want them to build the system you want, you'll have to pay them.
> But I guess Linux desktop has chosen its path of being only for tinkerers who are prepared to adopt an entire culture of quirks instead of users focusing on what’s important for them in their own lives.
This betrays your attitude. You think what we do is not important. You don't care about the system, it's just "cognitive burden" to you. Only your "core tasks" matter.
"Users focusing on what’s important for them in their own lives" -- that's us. We just happen to care about and focus on the system itself. We enjoy the freedom to rebuild the system according to our vision of how things should work.
Numerous independent tinkerers developing their own systems naturally leads to inconsistency. It's a very organic process. It's a mess, but that's okay. Our freedom is far more important than conforming to some "standard" in order to "reduce cognitive load".
If solutions converge, let them do so for the right reasons, namely that it leads to a better system for us. Other people don't really matter.
hulitu 6 hours ago [-]
> Devs do not get to decide how central a terminal is to my workflow, and whether that terminal app deserves to have the right to tell me that it’s now a special butterfly I need to accommodate my cognition for.
You must be new to computers. /s
Today's devs do not give a shit about user's needs. They just want change or profit.
atoav 6 hours ago [-]
> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.
As an university level educator: This is repeatedly a major hurdle for beginners, that makes the terminal (just text) feel like a different thing than just text to them. This and the fact that you can't just select the commands you have written with the mouse or with shift arrow makes beginners go mad, seemingly for no reason. And I count myself in there, I struggled with this for more than a year. When do you paste how? When donyou copy how?
The problem when you're learning this yourself is that you won't even have the correct vocabulary to describe what you want to know, it just feels like 99% of the world works and the 1% that doesn't is the terminal.
I get that this is historical, but if we want people to understand computers betond the consumer level this is literally like Blender changing from righ-click-select to left-click-select. Back then all the pros said it is no biggie just like you, but it turns out it was a biggie, because since then popularity exploded.
We terminal nerds lose nothing if more people understand terminals, quite the opposite.
sam_bristow 6 hours ago [-]
It's a pain for even experienced users. Popping open the developer tools in the browser because you've done Ctrl-Shift-C is annoying, accidentally calling a group chat of 50 people in MS Teams for the same reason is really annoying.
PhilipRoman 6 hours ago [-]
Ok as much as I like keyboard shortcuts, having a shortcut for making calls is just cruel.
The ctrl-c thing isn't a big deal for me since I copy text to clipboard either using tmux (just selecting is enough) or piping the terminal screen to vim (where I've mapped it to just +)
grues-dinner 5 hours ago [-]
Oh thank God it's not just me. At least have a confirmation popup for that! Ctrl+Shift+C, Enter isn't exactly onerous for Teams power users.
koiueo 6 hours ago [-]
In ideal world I'd want to have consistent copy/paste. I'm not saying it's perfect now. I'm just arguing that there are bigger UX problems IMO.
BTW, text selection in terminals seems much more annoying to me, than the necessity to press Shift when copying.
swiftcoder 6 hours ago [-]
That's kind of making the perfect-the-enemy-of-the-good. We can fix the copy/paste situation now, we can't necessarily fix the bigger problems so easily.
koiueo 6 hours ago [-]
But what is the solution? I don't see it.
Doing meta+c/v like in mac?
Thanks, no. Meta is allocated for windows manipulations in all my setups, and I'm pretty confident the approach where modifier keys are tied to specific "layers" of functionality is a more sound approach
trinix912 5 hours ago [-]
So we shouldn't go with the obvious solution that will also take the least effort to teach people (pressing the key next to Ctrl instead of Ctrl) because a few people out there have already set those shortcuts to do something magical on their machines?
cycomanic 4 hours ago [-]
Why is that more obvious than simply adding the shift to all copy operations? Changing to use the windows/options key is a terrible idea.
Copy/paste would be the only operations to use the windows/options key inside of programs, so much for consistency! If we are talking about changing all keyboard shortcuts to use windows/option key instead of CTRL is even worse, you are suggesting we should suddenly change all shortcuts for everyone, because some people can't remember to press the shift in the terminal?
And then there's the fact that pretty much all window managers/desktops use the window/option key for window manipulation (which sort of makes sense). That's not a few people that is almost everyone using keyboard shortcuts of their desktop environment.
trinix912 3 hours ago [-]
If the aim is to have an elegant, OS-wide solution, changing it to the Windows/Meta key makes more sense semantically than keeping it in the realm of program-specific Ctrl shortcuts.
Windows already has WinKey+V which brings up the clipboard manager.
> If we are talking about changing all keyboard shortcuts to use windows/option key instead of CTRL is even worse, you are suggesting we should suddenly change all shortcuts for everyone, because some people can't remember to press the shift in the terminal?
I only said that we should not subtract using Win/Meta key as an option just because some people have fancy setups that already use that. You implied the rest.
koiueo 4 hours ago [-]
Ctrl isn't near Cmd on my keyboard. And wasn't traditionally, even on first apple computers it resided where modern caps lock (an absolute waste of space) is.
Your solution is obvious to you, because you don't want to acknowledge the needs of others.
Alt+C/V, if anything, should be a better compromise, IMO. But it's still a compromise, not an obvious solution.
swiftcoder 5 hours ago [-]
Re the Mac like approach, I don't think that's actually all that incompatible. Yes, everyone would have to rejig their window manipulation a little, but keyboard shortcuts are a fundamentally different "layer" to ANSI escape sequences...
koiueo 4 hours ago [-]
Totally agree on ANSI escape.
But then to me windows manipulations is also an entirely different "layer".
Conceptually copy/paste could fit into that layer. It's like cross-window interface.
But what do we do with ctrl-z and ctrl-a, which are strictly text manipulation?
That's why Alt, IMO, would be a better modifier. And it all organizes into layers like this:
Ctrl - common ctrl sequences (like on Mac today)
Alt - app layer (still works for terminal UIs btw, even today)
Win - os/de/win layer
trinix912 2 hours ago [-]
But wouldn't it make more sense to use the Win key for it than Alt? I think copy/paste could fit into the OS/DE layer.
koiueo 2 hours ago [-]
Maybe. It's borderline text-editing (the majority of usages are text, and probably within the same application).
Also if we consider, how it's implemented: the app is responsible for content-type negotiation, if I copy a file in my file manager, it's the file manager's responsibility to yield file contents of I paste to another file manager, and yield the file:// uri if I paste to a text editor. So also border-line app functionality...
As I said, I don't see an obvious solution, and even if I had full freedom to design everything from scratch, I don't know which option I'd pick.
swiftcoder 5 hours ago [-]
I should probably have said "give people the tools to solve". The solution in the OP won't work out of the box for most people, but it would let everyone with a programmable keyboard bind to whatever they like
matheusmoreira 3 hours ago [-]
> that makes the terminal (just text) feel like a different thing than just text to them
Terminals are a lot more than just text. They were once physical machines. Now they are software emulating those old machines. These machines, physical or virtual, are controlled via in-band signaling. In many ways they are like extremely primitive browsers. Terminals are so old they actually predate copy paste.
> it just feels like 99% of the world works and the 1% that doesn't is the terminal
They don't actually work like all the other applications. They are completely different. Terminals are extremely complex legacy devices that require special kernel support to even work. The terminal line discipline is maintained by the kernel: Linux actually processes every single incoming and outgoing byte.
Nobody really expects to be able to paste text into a video game running inside a Super Nintendo emulator. Terminals are like that. It's actually amazing that modern terminal emulators were able to provide this feature.
> We terminal nerds lose nothing if more people understand terminals, quite the opposite.
Do you want people to actually understand terminals? To me it seems like you want to change terminals into something new that just happens to be easier to understand. They wouldn't really be terminals then, would they?
Things like ^C and ^D and ^[ are literally ASCII characters. Literally. Everything is ASCII text and that includes control characters, whose input is literally enabled by the Ctrl key. These bytes cause the terminal machine and sometimes even the kernel to do interesting things such as sending an interrupt signal to the slave program, closing its file descriptor or interpreting the next bytes as code in a sort of terminal instruction set. Typing on the keyboard just sends these codes into the system which can do any number of things in response.
We simply cannot have "normal" copy/paste with Ctrl-C and Ctrl-V. If we did this, terminals would no longer be the simple ASCII input devices described above.
Getting people to truly understand terminals means they have to understand all this.
echelon 7 hours ago [-]
> The universality of copy/paste is overrated. It's literally just adding shift in terminal emulators, no biggie.
I don't think anything has caused me more pain with computing than this.
And I'm including dealing with Python dependencies.
magic_hamster 6 hours ago [-]
I'm not sure I've seen the sci-fi movie where Apple is heralded as the golden standard of key bindings, but having used Macs for a few years in real life, I can attest the key combinations are an absolute atrocity for the reasons you mentioned and then some.
While I grew to accept some advantages of my Mac can't be easily replicated in other platforms, I think it is severely lacking in basic features, user experience and it's still occasionally infuriating even in 2025.
I do have a very long list of Mac gripes, as is probably deductable from this comment.
audiodude 6 hours ago [-]
While we're talking keyboards, what about emoji? Every messaging app has a different interface for them, some like Discord and Whatsapp allow you to use :smile: shortcuts, but the enumerated names are different across apps. I've occasionally gotten a dedicated OS emoji picker to show up on my Mac, but I don't know how.
On Ubuntu Cinnamon, I managed to create keyboard shortcuts for the 8 or so emoji I use the most by binding something called a "compose" key and modifying a .XCompose file, but it still took other config file gymnastics to make it persist between X sessions.
TheAceOfHearts 4 hours ago [-]
`Meta + .` opens an emoji picker on KDE. And you can type unicode with `Control + Shift + u`.
I've been meaning to look into this, but what I'd really love is a composer which can insert any text, emoji, or unicode character based on whatever alias I give it. I'd probably leverage more of unicode if I should hit a shortcut and type wd to summon a wave dash (〜).
account42 2 minutes ago [-]
~/.XCompose might be what you are looking for.
Support varies - GTK needs an environment variable to use it and Qt (since version 5) only uses the first code point of the result. No idea about Wayland support or alternatives.
voidUpdate 4 hours ago [-]
Windows does a similar thing with win+. (I forget if win maps to the meta key on linuxes)
numpad0 5 hours ago [-]
That's just regular keyboard for CJK languages. "today" -> "2025/08/15 Fri", "cry" -> ":crying_face:", etc. It's just small extension to regular "keycodes to full UTF-8 gibberish" process that input method editors handle.
There's nothing wrong if someone make ones for en, fr, de, in my opinion. Correction-plus-conversations like "hors douvray" to "hors-d'œuvre" in one key is going go be useful.
4lejandrito 6 hours ago [-]
Control + Command + Space
audiodude 6 hours ago [-]
Crazy, thanks!
SkiFire13 5 hours ago [-]
> I've occasionally gotten a dedicated OS emoji picker to show up on my Mac, but I don't know how.
On mine it shows up when I accidentally press the Fn key, which is very inconveniently placed where every other keyboard places the Ctrl key...
cryptonector 7 hours ago [-]
I use ctrl-Ins/shift-Ins and it works in my terminals and in the browser. I've not checked if it works in other apps because ctrl-c/ctrl-v always work in other apps. I'd be happy if ctrl-Ins/shift-Ins just always worked; I don't need innovation here.
wongogue 6 hours ago [-]
Innovation would be to actually have that key on most laptop keyboards.
jorams 1 hours ago [-]
Almost every laptop that isn't a MacBook has an insert key. The only other manufacturer I've seen leave it out is HP, and then only on some models.
jsnell 1 hours ago [-]
For the first couple of pages I thought that the article was a gag, and {C,S}-Insert was going to be the punchline.
weinzierl 6 hours ago [-]
I think Apple did the right thing by keeping GUI shortcuts separate from terminal control codes.
I never understood why the Linux GUI world ran blindly after Windows and emulated every pattern, good or bad. And yes, I know that Ctrl-C/Ctrl-P for Copy/Paste are much older and came out of IBM's CUA and SAA initiatives. What matters is that with the Mac we had a clear role model how to handle this aspect of GUI cleanly but me missed it.
While we’re at it, I’m still on the lookout for IBM’s original SAA and CUA documentation. If anyone has these lying around, I’d be interested
Dwedit 5 hours ago [-]
Ctrl+Ins, Shift+Ins, Shift+Del are the traditional shortcut keys that predate Ctrl+C, Ctrl+V, Ctrl+X. They still work on many Windows programs.
Someone 5 hours ago [-]
> I think Apple did the right thing by keeping GUI shortcuts separate from terminal control codes
They are separate because they ditched terminal shortcuts and later begrudgingly brought them back. The original Mac didn’t have a control key. They added it back in 1987 because of pressure of terminal emulator programs.
timuckun 6 hours ago [-]
Probably because of Miguel and his fascination with windows.
meitham 7 hours ago [-]
I like how Apple introduced the CMD key, with copy/paste linked to it in the terminal, leaving CTRL to work as intended. Even outside the terminal basic emacs key binding work as intended, such as c-k c-u etc
AnonymousPlanet 7 hours ago [-]
That's an arrangement I also really appreciate. But the origins are different from what most might assume.
Apple introduced copy and paste in 1983 using the command key. Microsoft later copied the idea using the control key because PCs lacked a command key [1].
X had super, meta, hyper keys before the PC's stunted set of modifiers became a standard [2]. Microsoft and the PC are rarely the origins of things, mainly because CP/M, DOS and later Windows were poor, amateurish, and incomplete copies of other systems.
I use Toshy along with an Apple keyboard to work around Linux distros' unfortunate Windowsiness here but I really really wish someone would release a fully fledged distro or DE put together with Apple keyboards in mind.
There's a lot of things about Apple I dislike but it's clear Microsoft's overloading of Ctrl for GUI shortcuts was a move made with complete disregard for terminal users, & one that's resulted in decades of pain for anyone regularly switching between GUI & terminal contexts, & I have to give it to Apple that Cmd was clearly designed to respect, retain & augment optimal terminal use.
koiueo 7 hours ago [-]
OTOH, Microsoft's introduction of "menu accelerators" (Alt+*) is an incredible productivity booster (which luckily most Linux graphical toolkits have adopted).
I got to appreciate it only after I had to use macOS at work.
Somehow I got used to Ctrl workarounds in terminal emulators (just add shift). But the lack of accelerators bugs me immensely.
lucideer 6 hours ago [-]
I've always found menu accelerators odd.
I find them a little too dependent on individual app developers word choices to have any kind of consistency across apps I use, plus I tend not to use menus for anything other than infrequent settings changes. Given that they haven't seemed substantially different to macos displaying annotations for bound shortcuts within the menus.
(admittedly I use mac in work & my personal computers at home have all been Linux since my Windows 2003 workstation died, so my knowledge of modern windows apps & their attached accelerators is rusty & I'm probably biased here)
koiueo 6 hours ago [-]
The last windows I used was XP. But accelerators do work in Linux.
And they are not just about menus: in any modal window I can do Alt+O for Ok. And this paradigm allows discoverability, I don't need to memorize shortcuts, I just hold Alt and look for underscored letters – that's how GUI should be IMO.
It's not perfect, and if I were designing UI from scratch, I'd made this feature modal instead of allocating entire physical key for that (like they do hints in vim-like browsers).
> I like how Apple introduced the CMD key, with copy/paste linked to it in
As someone who switches between macOS and Linux every day, the change of control-key from CTRL to CMD is hella annoying. I am always pressing the wrong combo on macOS.
npteljes 4 hours ago [-]
I completely agree. If only Windows also had WinKey+C/X/V as shortcuts, it would make so much sense in other Windows software too. Same with ALT+TAB and ALT+F4, CTRL+SPACE etc, these should also be handled by the win key. Then the Win/Cmd key would be assigned to OS functions, and the rest of them could be assigned to application functions, providing a clean separation.
rafram 7 hours ago [-]
Non-Mac keyboards have a meta / “Windows” key as well, usually sitting there doing nothing.
samlinnfer 7 hours ago [-]
On Linux it is often already used for window manager specific shortcuts.
cycomanic 7 hours ago [-]
They are the most common modifier key for tiling window managers. It's very likely one of the most often pressed key in my setup.
npteljes 4 hours ago [-]
Yeah, that is the most sensible choice. OS key to interact with the OS, rest of the keys to interact with the application.
account42 20 minutes ago [-]
Linux already has (or had) a universal copy paste: selection and middle click.
jmclnx 12 minutes ago [-]
Maybe depends upon the DE/WM you are using.
UN*X has 2 copy/paste buffers and they both work on Slackware with a Window Manager under X11 as you mentioned. I think the same is true with DE.
Is that not the case with Wayland ?
Anyway, I always liked how these worked when compared to Microsoft. Again, I do not what to see this change.
Plus we already have enough keys on our keyboard. I think Microsoft is in the process of adding an AI key, crazy. I do not look forward to 1000 keys on a laptop keyboard, already I fat finger the current keyboards too much.
dajtxx 6 hours ago [-]
I used stty to make interrupt ktrl-k, then configured the terminal app to make copy/paste ctrl-c/ctrl-v.
I use copy/paste more than I use interrupt.
I hated MacOS keyboard shortcuts at first, but cmd-c/cmd-v do work around this problem.
biehl 5 hours ago [-]
Lovely. Do you have some tips for that? Something you put in bashrc?
dsr_ 2 hours ago [-]
I have a mouse with an interesting number of buttons. (Elecom EX-G Pro; I recommend it if you have large hands and like thumb trackballs.)
So I ran xev to see what buttons they mapped to, and chose:
which my fingers have learned work everywhere except Chrome. Thanks, Google.
cncjchsue7 7 hours ago [-]
We gonna get support for keys that don't exist on any modern keyboards, don't worry though you can remap them or bind them to change mplicated macro layers in your expensive mechanical keyboards.
Do all that and you won't need those two lines of xinit.rc
cryptonector 7 hours ago [-]
Has no one noticed that ctrl-Ins/shift-Ins are almost universal, and they work in Windows and on Linux?
swiftcoder 6 hours ago [-]
Ins just doesn't exist on a lot of laptop keyboards, which kind of limits adoption.
trinix912 5 hours ago [-]
Even when the Ins and Del are there, they're at the far right top of the keyboard, which requires moving the hand to reach them every time.
It used to be less of a hassle when those shortcuts first appeared (with IBM CUA), as Ins/Del were just slightly above the arrow keys that you'd use to select the text prior to copying/cutting it anyways.
fmajid 6 hours ago [-]
Much easier would be to have all apps treat C-S-C as copy and C-S-V as paste like the terminal does. In Chrome this starts the inspector. I changed jobs and went from a Mac to Linux and muscle memory keeps tripping me.
camdroidw 5 hours ago [-]
Hopefully not UI designer!
v9v 6 hours ago [-]
In Emacs if CUA mode is on, C-c behaves as copy if any text is selected (and if no other keys have been pressed within a short time). To send a C-c when text is selected you do a C-S-c instead. Similarly in Windows Terminal I remember C-c works as copy without any issue (it deselects the text with the first C-c IIRC, so if you do two C-c's with text selected you copy and then send an interrupt).
Do any linux terminals implement anything like this? Why resort to adding new keys to keyboards?
mockingloris 6 hours ago [-]
Been a linux user since 2016 when I found an Ubuntu 16 installation CD in a drawer wirh old books. The thing for me is having ctrl+v paste without formatting. (If I need to retain formatting, I will gladly do ctrl+shift+v)
Maybe it's just me but, I'd gladly scroll endlessly looking at pictures of old keyboards / HID devices. (I use a Fellows KU-9938 Split Keyboard and a Kensignton)
saurik 7 hours ago [-]
ctrl/shift-insert?
koiueo 7 hours ago [-]
With many laptop vendors placing the insert key in the least ergonomic location or on FN layer, it's not really an option, unfortunately
saurik 5 hours ago [-]
I don't even have an fn key, much less an insert, on my hacked-up Chromebook, so I have right-alt set to alt-gr and I mapped alt-gr+enter to insert (and alt-gr+backspace to delete) in my X key map, and, even still, it honesty feels very ergonomic to hit ctrl/shift-insert?
(FWIW, the real problem is that the behavior is inconsistent with respect to what it pastes from :/. Notably, Firefox does something unusual and there has been a bug open for over two decades to fix it... before you say "well then, go submit a patch", someone did, lol omg.)
cryptonector 7 hours ago [-]
Rite? But no, apparently you and I are the only ones who know this.
ragnarook 5 hours ago [-]
[dead]
voidUpdate 4 hours ago [-]
With the author's Corne keymap, wouldn't holding down the backspace key to access the "raise" layer start deleting text?
rgoulter 4 hours ago [-]
It's a 'tap-hold' key, so the "tap" functionality is activated separately from its "hold" functionality.
Though, in order to get the same effect as "hold down backspace", e.g. QMK lets you have "tap then hold" as a way of invoking that functionality.
deknos 5 hours ago [-]
instead of some universal shortcuts, i would prefer to have another meta key, that we finally can do another-meta+ctrl+alt+ascii for more combinations :D
universal shortcuts are overrated and get in your way anyway :D
eviks 6 hours ago [-]
> To trigger the copy or paste keyboard actions, software has to bind these key codes to actions. Software toolkits or apps themselves are responsible for this.
If only the universal subset of communication maintained by the OS were actual actions
atmanactive 2 hours ago [-]
So what ARE the key codes for dedicated copy and paste keys?
Tor3 4 hours ago [-]
We already had a universal copy/paste in Linux: Mark with left mouse button, paste with middle button. This used to work for just about everything.
However, lately browsers started to ignore this when I mark the URL and try to paste it elsewhere, for example. Instead I get the old clipboard. I have to use the left button multiple times - and it works.
Falling back to Windows-style copy/paste, either with keys or pull-down menus with "copy" and later "paste" is, to me, a huge, inefficient step backwards and it's frustrating me every day.
Addon:
For purely non-mouse work, think serial terminal, I for one want Emacs bindings. Though that's typically configurable for the shell anyway, so everyone can choose what they prefer.
Propelloni 4 hours ago [-]
> We already had a universal copy/paste in Linux: Mark with left mouse button, paste with middle button.
We still have it, at least for text. I just copied the little quote above with left mouse highlight, middle mouse paste while writing this comment in Firefox in Gnome 48 with Wayland. I use it a lot on the terminal.
What doesn't appear to work anymore (at least in Wayland) is copying a selection as a bitmap into a bitmap editor, ie. paint. Only a few decades ago that used to work, I remember that.
Tor3 4 hours ago [-]
We still have it, it's just that we don't have it everywhere anymore. Which truly breaks up the workflow, or how I do things.
nullc 4 hours ago [-]
I think the multiple clipboards are great. My only regret is that there aren't more of them. Three would be excellent. But having multiple is very good, both for the pattern of "paste one thing over and over again, interspersed with copying and pasting other things" and for the pattern of "copy 1; copy 2; paste 1; paste 2" or "copy1; copy2; paste 2; paste 1" with only a single application switch.
When firefox screwed up the address bar so that the left-click/middle-click didn't work right was easily the worst step down in computing for me in modern history. Initially you could recover the non-chrome like behavior with a preference but they eventually broke that too.
sugarpimpdorsey 4 hours ago [-]
I thought "finally, Linux is adopting CUA", then realized this was a stealthy ad selling me remappable keyboards.
enricozb 5 hours ago [-]
I just remap my terminal to have Ctrl-X to send SIGHUP, and Ctrl-C to copy. X looks more like a kill to me anyways.
globular-toast 6 hours ago [-]
Not enough people know that you can just select text then middle click somewhere to paste it. No keys required and yes it works with all terminal emulators I've tried. This has been default behaviour on Linux desktops for as long as I've used it (decades).
Tor3 4 hours ago [-]
The problem with this (and to me it's a super annoying problem - marking and pasting with left and middle button is super fast and efficient) is that some browsers (or maybe it's the toolkits behind them) start to either ignore this functionality or force you to repeat the action before it works.
arp242 32 minutes ago [-]
Depends what you mean with "to select something"; for example if you click on the URL bar in Firefox then all the text is automatically selected. Should that count as the user "selecting" something? Perhaps not? None of this is very straight-forward.
globular-toast 4 hours ago [-]
Yeah, I've noticed this with "some browsers" (ie. Chrome).
It's reason enough for me to stick with Firefox.
cycomanic 3 hours ago [-]
I'm almost exclusively using firefox and I encounter it on some websites and not others. In particular selection in code boxes is the thing that often doesn't work. So I suspect it's actually not the browsers but some websites playing weird js shenanigans.
SkiFire13 5 hours ago [-]
The fact there is a totally different way to copy text in the terminal is the issue, it just breaks the common mental model. Even worse, this shortcut _requires using a mouse_, and not just for copying, also for selecting!
spauldo 5 hours ago [-]
X has had two clipboards for longer than I've been using it, which is nearly three decades.
If your mental model of clipboard interaction only involves a single clipboard, and you use X, your mental model is simply wrong.
Sure, you could change X to match your mental model, but now you've broken the mental models of everyone who actually learned to use the software. And one more useful feature that makes X nice to use gets sacrificed to please the people who came from Windows but desperately want everything to work like Windows.
globular-toast 4 hours ago [-]
How would you be copy/pasting in a terminal emulator without a mouse?
Any time I've seen someone do it it's: mouse to select, keyboard to copy, mouse to select other place, keyboard to paste.
I cringe every time because it could be just: mouse to select, mouse to select and paste it in the other place with one click.
kid64 5 hours ago [-]
What about cut?
WesolyKubeczek 6 hours ago [-]
Wouldn't it be darn nice, though, if there was a universal mechanism for apps to announce which shortcut they have available and a centralized way to configure them all?
For example, I was able to assign copy/paste keys to the corresponding actions in the GTK keybindings, and it worked like charm, except in Chrome. That is, in Chrome, web content respected these keybindings, but the browser UI didn't. So I could use the keys on textareas and inputs all I wanted, but paste into the address bar? Nooooo, BECAUSE FUCKING CHROME HAS THEM HARDCODED per platform!
(However, in Firefox it worked just fine across the whole UI.)
TacticalCoder 2 hours ago [-]
[dead]
antonvs 6 hours ago [-]
“The Year of the Linux Desktop” will be when copy/pasted is solved.
A bigger UX problem (on Linux) imo is the multitude of clipboards, we have x11, vim... Those can be synchronized or not, they manifest different behaviors...
And btw while apple is often offered as some golden standard for key bindings, I think the situation there is much (MUCH) worse: apps often intercept and handle common combinations on their own, with unclear precedence, which leads to non-deterministic behavior and a complete mess if you want to override any standard combination.
Thank you. That is absolutely the case. As someone who had to switch to Mac for work, I found the keybinding situation to be a complete mess. It's also incredibly hard to track down and change certain keybindings, many apps don't have any text configuration to easily modify and require you to go through their GUIs which require you to know what you are looking for (e.g., which app).
As in: most shortcts work the same across all apps?
> It's also incredibly hard to track down and change certain keybindings, many apps don't have any text configuration to easily modify and require you to go through their GUIs
Any action exposed in menus is handled on OS level in keyboard configuration: https://techtoro.io/blog/how-to-change-keyboard-shortcuts-on...
You select (typically via the mouse) something on the screen. The client (the software that handles this, e.g.terminal emulator, browser, office editing suite) declares ownership on a "selection". There are at least 3 of them: PRIMARY, SECONDARY, and CLIPBOARD.
Nothing gets copied!
When you go to some other client (or even the same) and do a "paste", a request is sent to the first client (the selection owner), "please give me the content". The second client gets the content and does whatever it wants with it, typically inserting it somewhere.
Contrast this way of operation to what other systems (like Windows and Mac) do: the content is copied to a central place, and then copied out to be "pasted". If one wants this behavior in X11, one needs to run something like a "clipboard manager" which can trivially implement this. I must admit, when using Windows, instead of Ctrl-V for pasting, I have completely switched to Windows-V, which gives you at least a history of the copied content.
Going further, on X11, the additional wonderful part is that there are also content-negotiation primitives built-in in this exchange!
So it could be the case that you select some formatted text in your browser, you want to paste it in your text editor (e.g. gvim), the editor asks ("give me the content, in Markdown (or HTML) format") and this is what gets transferred and eventually inserted. Or, if you select an image, you can paste the SVG text that generated it.
I have no idea what Wayland does, but this is another functionality that is extremely helpful and will be missed if not available, when/if X11 is replaced.
This is a gross oversimplification to how Windows manages the clipboard. In the general case, the situation is not much different from X11 and the data stays in the sending application until requested - and is lost on program exit.
I would probably like vim's + register to always sync with the X/Wayland clipboard where possible², but it is perhaps worth pointing out that vim has (at least?¹) 28 "clipboard" slots (+, *, a-z) and this is a feature not a bug. Having accepted that, I would likewise point out that X having a clipboard and selection buffer is an intentional feature. I'd support universally supporting one single shared clipboard that everything uses properly by default, but I wouldn't want to limit the other options to do it.
¹Edit: Nope, much more than that: https://learnvim.irian.to/basics/registers
²Edit: Oh, yes, I do agree that I would be in favor of making that the default register as well so that ex. just `yy`/`p` used it.
Agree. I got to realize how convenient it is to have one shared clipboard by default after I tried (doom)emacs: behaves like vim, has registers like vim, but default register uses the clipboard. I can still use all the registers as much as I like, but the default one is global and can be shared between apps.
I now configure my vim like this.
I still miss this, however, when working occasionally without a graphical session. Perhaps there's a solution, but I haven't yet bothered to look for it.
"This module configures Emacs for use in the terminal, by providing:
System clipboard integration (through an external clipboard program or OSC-52 escape codes in supported terminals). Cursor-shape changing across evil states (requires a terminal that supports it). Mouse support in the terminal."
I used to think this before I got a job in a Mac-only company. I've since installed Toshy on every Linux machine I own & the difference is night & day. Having to do something extra for terminals to achieve the thing that's so simple & natural (& frequent) in GUIs just feels like terminal emulators are being treated like second class citizens among the installed apps. Having the same shortcuts "Just Work" in exactly the same way through all apps isn't just more convenient, it feels like the OS is elevating terminals to an equal tier of integration.
Which I would've really expected more Linux users would value more than they seem to.
The common failure mode, for me, isn't hitting Ctrl-C for copy in a terminal by mistake, it's hitting Ctrl-Shift-C for copy in a browser and ending up with the console open, or hitting Ctrl-W to delete a word and having it close a tab.
The hacks about seems to be basically steal keyboard shortcuts the same way webpages already do; either through an extension[0] or modifying config-pref.js[1]. Neither of which seems very appealing to me. Though, funnily: I did hit Ctrl-W writing this message to delete a word; thank goodness for cache.
[0] https://addons.mozilla.org/en-US/firefox/addon/shortkeys/
[1] https://old.reddit.com/r/firefox/comments/kilmm2/restore_ctr...
My brain can "switch mode" when on a regular web page, but if I open some kind of "terminal in a page" (i.e. I the AWS console), then I'm 100% it will end up with a C-W.
It's right near Ctrl+Q, which usually quits an application.
While Q is mnemonic, W is not.
It's too ergonomic and requires very little wrist movement for such a destructive action.
I understand your pain, but I blame the author of this weird convention for the "close tab" action, whoever they are
For the specific case of copy-paste in a terminal, you either have to press something extra for paste or something extra for SIGINT - there is no secret third option. You could remap copy (bad for muscle memory) or remap sigint (similarly bad for muscle memory, but also confusing since many terminal apps mention CTRL+C explicitly).
I guess a better place for copy/paste would be WIN+C/V, since it feels like a global function and not an app-specific one, but the way clipboard is implemented makes it an app shortcut by necessity. This convention also doesn't hold with things like ALT+TAB (switch windows) and CTRL+Q (close window), both of which feel like "system" shortcuts but don't use WIN.
So I guess my point is...keybinds are already a mess "because legacy" and any attempt at solving that mess would just result in less universality and worse muscle memory, which goes against their whole reason for existing.
In the grand scheme of things, "when in a terminal, press shift to escape key combos" is a very easy convention to get used to. Also work for mouse integration, for example if you have vim open and mouse integration enabled, but want to select and copy using the system clipboard.
> there is no secret third option
I assume you're thinking of trying to use Ctrl-C in terminals? The secret third option is never using Ctrl at all outside of terminals.
> I guess a better place for copy/paste would be WIN+C/V
Yeah that would likely be the equivalent of Cmd if you're using a Windows keyboard. That is how it's configured across all apps by default in macOS & Toshy just ports that sensibility over to Linux.
Catches me out a bunch. There is also only a single copy buffer, so to copy from the terminal and paste into a browser I need to replace what was in my clipboard, drives me insane.
> Which I would've really expected more Linux users would value more than they seem to.
Because you get used to it and then don't think about it. I value having two copy buffers over consistency for the sake of consistency.
I guess this is likely an odd affordance to unix norms rather than a planned/intended shortcut (I've never tried it & never knew it worked anywhere). I'm not much of a mouse user in terminals though so I guess it would just be a little less natural.
* Two seperate buffers
* Separate shortcuts to paste them
* Selecting text _anywhere_ automatically puts it into the second buffer
I couldn't find anything that did this, so I just gave up and deal with it on my work laptop (and occasionally whine about it on HN when it comes up)
It’s a fun game to do I guess but if you become “more productive” by having a slightly quicker mechanism to find a file through 9 different chords on your terminal only interface - you likely aren’t solving problems that are worthwhile.
You reach a point of diminishing returns with everything. You can only gain so much knowledge/intelligence/experience before every increase in that becomes extremely difficult. Trying to become "smarter" when you are already "smart" is much harder than getting easy efficiency wins.
There are people that take it to the extreme of course, where they spend all their time on extremely tiny efficiency wins instead of learning how to program, but that's the same problem in reverse.
It's a pretty old concept, the first time I've seen it given a proper name was "aggregation of marginal gains" [0].
[0] https://jamesclear.com/marginal-gains
That's a very big fineprint. With three most popular apps among developers being (I imagine) browser, jetbrains ides and vs code derivatives, all being non-native, muscle memory becomes pretty unreliable.
But yeah, would be big, if it indeed was universally supported
It's likely that the users who find this annoying will simply stop using Linux.
It's literraly breaking your muscle memory for one of the most commonly used shortcuts for no reason. It's a pretty big ergonomic blunder
If we had physical keys, we could also fairly easily add multiple clipboards like Copy+2 or Copy+F2 could be clipboard #2 without impacting the basic ease of use.
That's an easy no, precisely because
> have at least 20 keys on my desktop keyboard that I never use
Very common operations should be ergonomic, i.e. have a convenient location. Unless you mean to make all keyboards split ergonomic with a thumb cluster, so you'd have prime space for copy and paste, adding bad 21st and 22nd key far away will be worse than a more convenient modifier
Also, you forgot laptops where there is not enough real estate to even fit the full standard desktop keyboard
(multiple clipboards would be a great benefit, though)
> adding bad 21st and 22nd key far away will be worse than a more convenient modifier
Even if in the scroll lock/pause-break region it would help a lot for those who struggle with modifier keys. With this option you could keep Ctrl+C/V.
That counts against you because now you have even fewer keys to work with to add copy/paste, shouldn't that extra physical key be instead used for those extra useful letters?
> First we have a large caps lock key and two alt keys.
My "Status quo" is using them for other better things. And right alt is also currently use for those non-ascii Europeans, so that's not an easy win. Caps lock might be, the current default is a disgraceful waste. So that only leaves Paste
> Even if in the scroll lock/pause-break region
Again, you don't have it on laptops, that's the main source of space constraints, so now you don't have universal muscle memory experience.
> With this option you could keep Ctrl+C/V
Hm, yeah, I thought of a universal replacement.
In the shell I want the super key or tab or something to mean "new list item" - no more escaping spaces (this will of course never happen in my lifetime - but if you're rebuilding technology post apocalypse with a clean slate...)
You can inject JS into every single page to fix it via an extension, but extensions don't have the ability to fix it otherwise. I suppose you could also intercept it in an IME?
You have to know what to add. Sometimes it is shift, sometimes (rxvt) it is alt.
The clipboard has always been annoying. Even today, you often see a "copy to clipboard" or something on a web page, and it never works on Linux. Not as I've got it configured, in any case.
That's weird. It's a pretty widely available Javascript API for years already. Nothing OS specific on the website's side. Are you running an ancient/fringe browser?
https://caniuse.com/mdn-api_clipboard_writetext
Edit: Hmm, got one already called clipman, and it can display the two types of selections, now just have to figure out how to use it.
It's an inversion. Instead of the user selecting and then having to figure things out, they declare an "intention to paste" and then do the selection.
In practical terms, they invoke the "use clipboard" feature then the code probes all the clipboards (tmux/primary/emacs/nvim/clipboard/secondary) and the user selects their text. One (or more) changes. That's the clipboard it's going to use.
I love the fact I can select from the terminal, or from the GUI, and I can use Shift + Insert or middle click.
I love how I can have another clipboard using Ctrl-C / Ctrl-V.
I use both on an everyday basis and has been for almost two decades.
anyone know the differences?
It's funny though because I'm so used to it I actually have it as part of my workflow and use the different clipboards differently. If I have to use a non-Linux machine for a while I suddenly feel crippled by only having the one.
That actually has become more annoying recently, because it seems to work very inconsistently in browsers now. Somehow some websites (e.g. The code blocks in webui, GitHub...) seem to not use the regular clipboard selection so pasting from that doesn't work (I hadnt had time to really investigate)
I am already cognitively burdened. I do not need developers telling me at what point the cumulative inconsistencies become a biggie. Copy-paste is a common action and each inconsistency I need to learn is away from my core tasks and ability to focus on those is already scarce as f.
Devs do not get to decide how central a terminal is to my workflow, and whether that terminal app deserves to have the right to tell me that it’s now a special butterfly I need to accommodate my cognition for.
But I guess Linux desktop has chosen its path of being only for tinkerers who are prepared to adopt an entire culture of quirks instead of users focusing on what’s important for them in their own lives.
I’m disappointed this still does not fix the core issue of this being broken for everyone by default.
In my experience Apple devs are the _most_ opionated in terms of telling users how they should use their machine. The UI controls are super touchpad-centric, and it's crazy that a community-driven project like i3 is light years ahead to macOS "wm" features (not to talk about the native UI management). Also they decide for you where the icons to close the windows are, you want to change them? Nope, sorry, you are doing it wrong and can't move them. Your keyboard? Also wrong, you should buy an apple one, otherwise your modifiers are all messed up. You don't use the application docking bar? Well, you are doing it wrong, you can reduce it, but can't remove it, it's always going to be there at the bottom.
There are countless of instances in which the only way to do something is the Apple way, so much so that everyone who switched from Linux to Mac I have spoken with essentially concluded that either you bend to how Apple decided things should be done, or you will be constantly fighting your own machine.
I appreciate that this means that if you start with Apple and get used to their way, you have no cognitive burden on how to do something, but when you use your machine every day, you want to decide how things work to reduce your cognitive load (I.e., this is more intuitive for me this way), and Apple really doesn't like that.
"What you're used to" is a major component of usability. I've had to do short stints on a macOS machine before, and find it a painful experience that I'm happy to be rid of when I'm done. People who are used to a macOS machine sometimes say the same thing about a Linux machine. They can both be right at the same time.
It isn't the only component of usability, to be clear, and it's also possible for applications to be objectively better. But familiarity and usability are often conflated.
First time I tried macOS I was impressed with the globally (so I thought) respected emacs bindings (^E, ^A, and especially ^N and ^P). But then I have painfully discovered that almost every(?) app just mimics the default scheme, but essentially implements its own handling, which leads to numerous inconsistencies spreading way beyond copy/paste. That's when I realized why most macOS users I've observed use touchpad to manipulate cursor during text editing – there's no reliable universally consistent way of doing this under macOS
macOS is not just "not ideal". It's as messy as other OSes, but with its own bag of unique warts.
But I understand it's easy to ignore them once you get used to them.
> Devs do not get to decide
I'm sorry but developers get to decide literally everything. They're the ones putting in the work. They build the systems they want for themselves. They solve the problems they personally care about in ways they personally feel is best.
If you want them to build the system you want, you'll have to pay them.
> But I guess Linux desktop has chosen its path of being only for tinkerers who are prepared to adopt an entire culture of quirks instead of users focusing on what’s important for them in their own lives.
This betrays your attitude. You think what we do is not important. You don't care about the system, it's just "cognitive burden" to you. Only your "core tasks" matter.
"Users focusing on what’s important for them in their own lives" -- that's us. We just happen to care about and focus on the system itself. We enjoy the freedom to rebuild the system according to our vision of how things should work.
Numerous independent tinkerers developing their own systems naturally leads to inconsistency. It's a very organic process. It's a mess, but that's okay. Our freedom is far more important than conforming to some "standard" in order to "reduce cognitive load".
If solutions converge, let them do so for the right reasons, namely that it leads to a better system for us. Other people don't really matter.
You must be new to computers. /s
Today's devs do not give a shit about user's needs. They just want change or profit.
As an university level educator: This is repeatedly a major hurdle for beginners, that makes the terminal (just text) feel like a different thing than just text to them. This and the fact that you can't just select the commands you have written with the mouse or with shift arrow makes beginners go mad, seemingly for no reason. And I count myself in there, I struggled with this for more than a year. When do you paste how? When donyou copy how?
The problem when you're learning this yourself is that you won't even have the correct vocabulary to describe what you want to know, it just feels like 99% of the world works and the 1% that doesn't is the terminal.
I get that this is historical, but if we want people to understand computers betond the consumer level this is literally like Blender changing from righ-click-select to left-click-select. Back then all the pros said it is no biggie just like you, but it turns out it was a biggie, because since then popularity exploded.
We terminal nerds lose nothing if more people understand terminals, quite the opposite.
The ctrl-c thing isn't a big deal for me since I copy text to clipboard either using tmux (just selecting is enough) or piping the terminal screen to vim (where I've mapped it to just +)
BTW, text selection in terminals seems much more annoying to me, than the necessity to press Shift when copying.
Doing meta+c/v like in mac?
Thanks, no. Meta is allocated for windows manipulations in all my setups, and I'm pretty confident the approach where modifier keys are tied to specific "layers" of functionality is a more sound approach
Copy/paste would be the only operations to use the windows/options key inside of programs, so much for consistency! If we are talking about changing all keyboard shortcuts to use windows/option key instead of CTRL is even worse, you are suggesting we should suddenly change all shortcuts for everyone, because some people can't remember to press the shift in the terminal?
And then there's the fact that pretty much all window managers/desktops use the window/option key for window manipulation (which sort of makes sense). That's not a few people that is almost everyone using keyboard shortcuts of their desktop environment.
Windows already has WinKey+V which brings up the clipboard manager.
> If we are talking about changing all keyboard shortcuts to use windows/option key instead of CTRL is even worse, you are suggesting we should suddenly change all shortcuts for everyone, because some people can't remember to press the shift in the terminal?
I only said that we should not subtract using Win/Meta key as an option just because some people have fancy setups that already use that. You implied the rest.
Your solution is obvious to you, because you don't want to acknowledge the needs of others.
Alt+C/V, if anything, should be a better compromise, IMO. But it's still a compromise, not an obvious solution.
Conceptually copy/paste could fit into that layer. It's like cross-window interface.
But what do we do with ctrl-z and ctrl-a, which are strictly text manipulation?
That's why Alt, IMO, would be a better modifier. And it all organizes into layers like this:
Ctrl - common ctrl sequences (like on Mac today)
Alt - app layer (still works for terminal UIs btw, even today)
Win - os/de/win layer
Also if we consider, how it's implemented: the app is responsible for content-type negotiation, if I copy a file in my file manager, it's the file manager's responsibility to yield file contents of I paste to another file manager, and yield the file:// uri if I paste to a text editor. So also border-line app functionality...
As I said, I don't see an obvious solution, and even if I had full freedom to design everything from scratch, I don't know which option I'd pick.
Terminals are a lot more than just text. They were once physical machines. Now they are software emulating those old machines. These machines, physical or virtual, are controlled via in-band signaling. In many ways they are like extremely primitive browsers. Terminals are so old they actually predate copy paste.
> it just feels like 99% of the world works and the 1% that doesn't is the terminal
They don't actually work like all the other applications. They are completely different. Terminals are extremely complex legacy devices that require special kernel support to even work. The terminal line discipline is maintained by the kernel: Linux actually processes every single incoming and outgoing byte.
Nobody really expects to be able to paste text into a video game running inside a Super Nintendo emulator. Terminals are like that. It's actually amazing that modern terminal emulators were able to provide this feature.
> We terminal nerds lose nothing if more people understand terminals, quite the opposite.
Do you want people to actually understand terminals? To me it seems like you want to change terminals into something new that just happens to be easier to understand. They wouldn't really be terminals then, would they?
Things like ^C and ^D and ^[ are literally ASCII characters. Literally. Everything is ASCII text and that includes control characters, whose input is literally enabled by the Ctrl key. These bytes cause the terminal machine and sometimes even the kernel to do interesting things such as sending an interrupt signal to the slave program, closing its file descriptor or interpreting the next bytes as code in a sort of terminal instruction set. Typing on the keyboard just sends these codes into the system which can do any number of things in response.
We simply cannot have "normal" copy/paste with Ctrl-C and Ctrl-V. If we did this, terminals would no longer be the simple ASCII input devices described above.
Getting people to truly understand terminals means they have to understand all this.
I don't think anything has caused me more pain with computing than this.
And I'm including dealing with Python dependencies.
While I grew to accept some advantages of my Mac can't be easily replicated in other platforms, I think it is severely lacking in basic features, user experience and it's still occasionally infuriating even in 2025.
I do have a very long list of Mac gripes, as is probably deductable from this comment.
On Ubuntu Cinnamon, I managed to create keyboard shortcuts for the 8 or so emoji I use the most by binding something called a "compose" key and modifying a .XCompose file, but it still took other config file gymnastics to make it persist between X sessions.
I've been meaning to look into this, but what I'd really love is a composer which can insert any text, emoji, or unicode character based on whatever alias I give it. I'd probably leverage more of unicode if I should hit a shortcut and type wd to summon a wave dash (〜).
Support varies - GTK needs an environment variable to use it and Qt (since version 5) only uses the first code point of the result. No idea about Wayland support or alternatives.
There's nothing wrong if someone make ones for en, fr, de, in my opinion. Correction-plus-conversations like "hors douvray" to "hors-d'œuvre" in one key is going go be useful.
On mine it shows up when I accidentally press the Fn key, which is very inconveniently placed where every other keyboard places the Ctrl key...
I never understood why the Linux GUI world ran blindly after Windows and emulated every pattern, good or bad. And yes, I know that Ctrl-C/Ctrl-P for Copy/Paste are much older and came out of IBM's CUA and SAA initiatives. What matters is that with the Mac we had a clear role model how to handle this aspect of GUI cleanly but me missed it.
While we’re at it, I’m still on the lookout for IBM’s original SAA and CUA documentation. If anyone has these lying around, I’d be interested
They are separate because they ditched terminal shortcuts and later begrudgingly brought them back. The original Mac didn’t have a control key. They added it back in 1987 because of pressure of terminal emulator programs.
Apple introduced copy and paste in 1983 using the command key. Microsoft later copied the idea using the control key because PCs lacked a command key [1].
X had super, meta, hyper keys before the PC's stunted set of modifiers became a standard [2]. Microsoft and the PC are rarely the origins of things, mainly because CP/M, DOS and later Windows were poor, amateurish, and incomplete copies of other systems.
[1] https://en.wikipedia.org/wiki/Cut,_copy,_and_paste
[2] https://en.wikipedia.org/wiki/Super_key_(keyboard_button)
There's a lot of things about Apple I dislike but it's clear Microsoft's overloading of Ctrl for GUI shortcuts was a move made with complete disregard for terminal users, & one that's resulted in decades of pain for anyone regularly switching between GUI & terminal contexts, & I have to give it to Apple that Cmd was clearly designed to respect, retain & augment optimal terminal use.
I got to appreciate it only after I had to use macOS at work.
Somehow I got used to Ctrl workarounds in terminal emulators (just add shift). But the lack of accelerators bugs me immensely.
I find them a little too dependent on individual app developers word choices to have any kind of consistency across apps I use, plus I tend not to use menus for anything other than infrequent settings changes. Given that they haven't seemed substantially different to macos displaying annotations for bound shortcuts within the menus.
(admittedly I use mac in work & my personal computers at home have all been Linux since my Windows 2003 workstation died, so my knowledge of modern windows apps & their attached accelerators is rusty & I'm probably biased here)
And they are not just about menus: in any modal window I can do Alt+O for Ok. And this paradigm allows discoverability, I don't need to memorize shortcuts, I just hold Alt and look for underscored letters – that's how GUI should be IMO.
It's not perfect, and if I were designing UI from scratch, I'd made this feature modal instead of allocating entire physical key for that (like they do hints in vim-like browsers).
As someone who switches between macOS and Linux every day, the change of control-key from CTRL to CMD is hella annoying. I am always pressing the wrong combo on macOS.
UN*X has 2 copy/paste buffers and they both work on Slackware with a Window Manager under X11 as you mentioned. I think the same is true with DE.
Is that not the case with Wayland ?
Anyway, I always liked how these worked when compared to Microsoft. Again, I do not what to see this change.
Plus we already have enough keys on our keyboard. I think Microsoft is in the process of adding an AI key, crazy. I do not look forward to 1000 keys on a laptop keyboard, already I fat finger the current keyboards too much.
I use copy/paste more than I use interrupt.
I hated MacOS keyboard shortcuts at first, but cmd-c/cmd-v do work around this problem.
So I ran xev to see what buttons they mapped to, and chose:
"xvkbd -text "\[XF86Copy]"" m:0x0 + b:8 "xvkbd -text "\[XF86Paste]"" m:0x0 + b:9
which my fingers have learned work everywhere except Chrome. Thanks, Google.
Do all that and you won't need those two lines of xinit.rc
It used to be less of a hassle when those shortcuts first appeared (with IBM CUA), as Ins/Del were just slightly above the arrow keys that you'd use to select the text prior to copying/cutting it anyways.
Do any linux terminals implement anything like this? Why resort to adding new keys to keyboards?
Maybe it's just me but, I'd gladly scroll endlessly looking at pictures of old keyboards / HID devices. (I use a Fellows KU-9938 Split Keyboard and a Kensignton)
(FWIW, the real problem is that the behavior is inconsistent with respect to what it pastes from :/. Notably, Firefox does something unusual and there has been a bug open for over two decades to fix it... before you say "well then, go submit a patch", someone did, lol omg.)
Though, in order to get the same effect as "hold down backspace", e.g. QMK lets you have "tap then hold" as a way of invoking that functionality.
universal shortcuts are overrated and get in your way anyway :D
If only the universal subset of communication maintained by the OS were actual actions
Addon: For purely non-mouse work, think serial terminal, I for one want Emacs bindings. Though that's typically configurable for the shell anyway, so everyone can choose what they prefer.
We still have it, at least for text. I just copied the little quote above with left mouse highlight, middle mouse paste while writing this comment in Firefox in Gnome 48 with Wayland. I use it a lot on the terminal.
What doesn't appear to work anymore (at least in Wayland) is copying a selection as a bitmap into a bitmap editor, ie. paint. Only a few decades ago that used to work, I remember that.
When firefox screwed up the address bar so that the left-click/middle-click didn't work right was easily the worst step down in computing for me in modern history. Initially you could recover the non-chrome like behavior with a preference but they eventually broke that too.
It's reason enough for me to stick with Firefox.
If your mental model of clipboard interaction only involves a single clipboard, and you use X, your mental model is simply wrong.
Sure, you could change X to match your mental model, but now you've broken the mental models of everyone who actually learned to use the software. And one more useful feature that makes X nice to use gets sacrificed to please the people who came from Windows but desperately want everything to work like Windows.
Any time I've seen someone do it it's: mouse to select, keyboard to copy, mouse to select other place, keyboard to paste.
I cringe every time because it could be just: mouse to select, mouse to select and paste it in the other place with one click.
For example, I was able to assign copy/paste keys to the corresponding actions in the GTK keybindings, and it worked like charm, except in Chrome. That is, in Chrome, web content respected these keybindings, but the browser UI didn't. So I could use the keys on textareas and inputs all I wanted, but paste into the address bar? Nooooo, BECAUSE FUCKING CHROME HAS THEM HARDCODED per platform!
(However, in Firefox it worked just fine across the whole UI.)