Who actually wants two separate (app-specific!) key bindings for “copy”, which is meant to be a system-wide action? Thats terribly silly and immediately leads to you accidentally killing programs in your terminal. A very silly design choice IMO.
> Linux/BSD UIs use the Control and Shift modifiers most heavily, instead of Command and Option.
I don't think I would have a severe objection to reversing terminal shortcuts (i.e. use Ctrl-c to copy, Ctrl-Shift-c to kill). But really, these are dev tools and I don't think the alternative shortcuts are that hard to get used to. On Linux it just becomes second nature that in the terminal the normal shortcuts are all prefixed with 'Shift', because there are a bunch of more useful shortcuts directly under the normal keys.
Edit: incidentally you can change this on Linux. It's configurable. I suppose not many people seem to want to, which is maybe its own response to your question. See this thread for example: https://www.linuxquestions.org/questions/linux-software-2/ch...
I dont think the OP’s original point was primarily that the defaults are terrible, in any case. Its that the management of keybindings is godawful. The configuration fix you linked makes this point precisely. In order to have consistency in a basic systemwide function like “copy” you have to dig through forums or bust out your terminal emulator’s man page.
The OP said "All the keybindings are wrong", so I responded with the assumption that they intended to complain about the keybindings (e.g. the use of Ctrl instead of Cmd). If we assume otherwise, all bets are off.
In any case, I think you're assuming too much about how intuitive the system you've grown accustomed to is to other people. I accidentally kill programs in the terminal when I use macOS, because I can't keep the Cmd and Ctrl shortcuts separate in my head. Is that Apple's fault, or is it just something I'm not used to?
IMO, desktop UI designers would like to have three things. The issue is that they're mutually incompatible.
1. Continuity with the ancient tradition of having Ctrl-c send a cancel/abort (or SIGINT) signal.
2. Having the common operation of copying some text mapped to [modifier]-c.
3. Having the most common modifier key be the key in the bottom left corner of the keyboard, which is Ctrl on most PC keyboards.
You can't have all three at once in the same application. macOS solves this problem by abandoning 3, and using Cmd-c to copy text. Most Linux / Unix distributions solve this by partially abandoning 2, by prefixing the shortcut with an additional modifier in terminal applications so that the normal shortcut can continue to be used elsewhere. In my opinion they're both valid approaches. Personally I detest having to grope to find the Cmd key and remap my modifiers using Karabiner on macOS.
> Would you expect your OS to have application-specific shortcuts for systemwide, cross-application functions like copy and paste?
Maybe? The point in the comment I left you is that some kind of expectation has to be violated here. I don't find the Linux choice (to remap a system-wide shortcut for a single developer-centric application) to be too intrusive. But YMMV.
Mac keyboards put fn in the bottom left. Personally (disclaimer: Mac user) the third point is the least important, and if this is a problem for you, you should remap the physical command and control keys, which is fairly trivial to do on macOS.
Heh, you're not going to like this, but I do remap the keys, just not that way. I have fn -> Cmd, Ctrl -> fn, Alt -> Ctrl, Cmd -> Alt. This requires Karabiner, AFAIK.
This sort of imitates what I consider a sane setup in most applications. That is, "copy" is bottom-left button plus c, just like it is in every other operating system.
For me, #3 is actually very important. As I mentioned above, I have a lot of trouble blindly finding the (physical) Cmd key on the MacBook keyboard. Whereas the fn key is trivial to find, it's just the bottom left.
