I read a lot of answers online that its a bad idea, but the arguments did not make a lot of sense. “it’s a heavily ingrained part of the eco system”. Well if I can change it, what’s the deal?
It makes more sense to make an interrupt signal be the harder shortcut, and copy to be ctrl+C, matching other programs and platforms.
The thing about “it’s a heavily ingrained part of the eco system” is that, it really is. We’re not talking about user habits here, we’re talking the whole ecosystem of software that expects it to work that way: the kernel, the shells, SSH, the terminal emulators, the virtual consoles.
Under the hood, those aren’t keyboard shortcuts, they’re control characters and you make those with Ctrl plus a key, and it’s handled by the kernel itself so you’d have to run a custom kernel on every machine you use just so you can use Ctrl+C for copy.
So, on the wire those have to stay. You can configure your terminal emulator to maybe swap Ctrl and Super as super doesn’t mean anything for a terminal. That’s pretty much how things happen to be on macOS, since copy/paste is Super+C/V. Then your Ctrl key is free for anything you might want.
Some extra docs about all the codes: it’s far from just ^C: https://man7.org/linux/man-pages/man4/console_codes.4.html
Isn’t it enough just to instruct stty to take the new shortcut, instead of running a custom kernel? Is there anything left out by doing this?
idk it’s weird to have
^C,^Mand other control characters and have one be ctrl+shift+c and the other be control+mIt shouldn’t be too difficult to remap them all to the ctrl+shift equivalent. I just have to make sure I get all of them.
Very interesting! Was always annoyed by the Ctrl+Shift+C