Historically, Ctrl+c has been used to interrupt a process on terminals. This applies on Linux, but also applied to BSDs and Unixes before it. This is still true, even today, on pretty much any terminal emulator.
When mice became a thing, one could simply select text and then click mouse2 to paste it. mouse2 was the right mouse button back when mice had two buttons, and became the middle mouse button now that mice typically have three buttons (or three-finger tap on touchpads).
When text is selected it becomes the PRIMARY SELECTION, and can be pasted
anywhere. Again, this still works on Linux nowadays as well as many other
platforms. This feature exists in parallel to the more popularly known
clipboard.
The clipboard
The eighties came, and Apple refined this concept into the form commonly known today. The action of “copying” text became explicit. One could select text for a multitude of reasons (e.g.: to then click on the “bold” button), so having “copy” be an explicit action made sense.
Apple defined some keyboard mapping for these actions which remain the same to this today:
- Cmd+x to cut 1
- Cmd+c to copy
- Cmd+v to paste
You’ll notice that someone did their homework and made sure to pick a key combination that wasn’t already used for something else.
Microsoft, faithful to its style, copied the whole idea, but changed it slightly:
- Ctrl+x to cut
- Ctrl+c to copy
- Ctrl+v to paste
You’ll immediately notice an issue here: Ctrl+c already had a different usage, so we have a collision. Of course, Windows is not like all the other operating systems, and didn’t have terminals, so this was never a problem.
Modern terminals
At some point in history, this same clipboard made its way into the graphical interfaces of open source desktop environments (mainly GNOME and KDE) and trickled into all other applications. However, the key mappings were copied from windows.
Because terminals already had a use for Ctrl+c, they had to use something else to paste from the clipboard. The following mappings were chose, and remain the same on most non-Apple platforms even today use:
- Ctrl+Shift+x to cut
- Ctrl+Shift+c to copy
- Ctrl+Shift+v to paste
This is terrible, mostly because copy-pasting is standard on most Linux apps except terminals, where it has to be different because of this collision.
Using Ctrl+Shift+c to copy on terminals is terrible ergonomics, and a permanent source of confusion. New users are always confused (understandably so), and even seasoned users will occasionally get it wrong (and kill a process trying to paste into it). It’s also frequently a very hard/painful combination to press on laptop keyboards, due to the size and position of both modifiers.
Using Super+c
Using Super+c to copy (much like has been the case on Apple’s OSs since the eighties) fixes this problem: all programs can use the same mapping, and it’s a lot easier to press than. However, changing this is tricky. Asking every toolkit and app developer to change their mappings is not feasible at all; most won’t even think it’s a good idea, and users would revolt in uproar.
Luckily, there exists an escape hatch! There exist a few special keys called XF86Copy, XF86Paste, XF86Cut. These are those special media keys on some keyboards which have the actual copy, paste and cut icons on them respectively, and do exactly that.
So it’s possible to configure a system to simulate XF86Copy being pressed when one presses Cmd+c. And this should work pretty much everywhere. Both in terminals and GUI applications! A few applications might not interpret XF86Copy, but that’s a valid bug report that one can reasonably expect to be addressed.
On wayland compositors, simulating this key can be achieved with:
wtype -P XF86Copy
So on swaywm one might configure:
bindsym Mod4+x exec wtype -P XF86Cut
bindsym Mod4+c exec wtype -P XF86Copy
bindsym Mod4+v exec wtype -P XF86Paste
Care should be taken to remap any actions previously mapped to these combinations.
If you try this out, I’m very curious to hear your experience!
Cmd, also known as Command, Super, Mod4 or Windows Key. ↩︎