Most terminals today have a copy-on-select feature, which means you don't need to ctrl-c at all. Just select and ctrl-v.
The Windows GUI copied the Mac’s keyboard shortcuts (originally from Lisa?) but didn't have a dedicated key for them so re-used the existing Ctrl key, which already had a meaning on text-based operating systems. (This happened because Microsoft had no input into hardware keyboard layouts, and wanted to make software compatible with the plethora of IBM-Model-M-layout keyboards available in 1985–1990.)
Then Linux GUIs wholesale copied every feature of Windows they could including the keyboard shortcuts, in a context where this was even worse, because now existing Ctrl-based shortcuts from terminal software were directly in conflict with new Ctrl-based shortcuts from Windows.
Except for that particular action (select some text on terminal then copy) you have to use mouse to do the "select" part anyways.
Where a mouse is really needed is in action games. A touchpad is too slow there.
In this context there is a lot of difference between a mouse and a touchpad. For example, I select text with the keyboard most of the times in emacs and in any other input box (not in vim, is it even possible?). So I'd lose time by reaching to a mouse. I hardly have to move my hands to use my touchpad.
The thing is it's the default on iTerm2 on the Mac, so every time I set it up I spend a week thinking "why is my clipboard always completely full of shite" before I remember and turn it off.
(YMMV, you may like this, you may actually have proper clipboard management, and so on. I didn't say this was a logically consistent rant.)
It's possible that this isn't enabled by default, but I'm virtually certain it is because it catches me out every time.
X11 by contrast has by default 2 buffers so you never clobber your buffer filled by control+c however some clipboard management software optionally syncs the 2 buffers bringing back the behavior you dislike.
Personally I find this method much more usable than the traditional windows-style clipboard.
Either way, you want to generally avoid C-c for copy in terminals because it's already bound to the all important "send sigterm signal to foreground process". This is on a long list of ancient cruft that exists in terminal emulators and shells.
Absolutely. But it's not cruft. It's the original meaning of the character, and the standard method of generation.
Ctrl+C is just like any other keypress which maps to a standard ASCII representation.
The error is in reusing ASCII chars for GUI actions. This was an obviously-bad idea in 1985, and it has never become a better idea.
My perspective is that control characters were a bad idea from the beginning. Then again, so are ubiquitous predefined keyboard shortcuts like C-c.
Having user interaction predefined makes it more difficult to change keyboard layouts and shapes.
So if you have in-band signalling, you need a method to generate those signals. I don't think there was any other viable way to solve this problem, and honestly it has worked almost flawlessly.
Of course Microsoft is a big exception, but that could hardly have been predicted 20 years earlier.
My point here is that we are so steeped into tradition that usability suffers.
In-band signalling is inherently a bit of an architectural challenge. But the problem is solved. The entire internet is run on in-band signalling! We're going on 35 years for TCP/IP, and more like 50 for ASCII control chars. They work very, very well.
Yes, Microsoft broke control character generation for users of their OS, but that's a compartmentalized failure, and easily avoided. The Ctrl+Shift GUI workaround in Windows (and copied in Linux) is not elegant. But any alternative without control chars would be a total loss of functionality.
Ctrl+C being broken by Copy is a trivial example. There's a whole alphabet of control chars (in fact there are 32), and we all use more of them than most people realize[0]. Some have dedicated keys on the keyboard (backspace, return), but obviously not all of them.
I use about a dozen control characters regularly. This is not unusual for someone who works closely with server operating systems.
[0] I'm not sure how to gauge your knowledge of communication signalling or protocols, so I apologize if I'm being pedantic. It sounds like you have ideas about alternatives (and this is interesting to me), so I am curious about any specifics you can share or link to.
I am serious about not wanting users of Kinto to feel like they are dying a death of a thousand paper cuts because they have to stop what they are doing and add yet another keymapping. Kinto can't get every app remapped right 100% of the time - but it gets awfully close still.
Initially I did not write Kinto that way because I didn't think it to be all that possible and with setxkbmap it was very difficult to understand and properly implement such a configuration. Probonopd, who does write some wonderful articles about UX related topics that I've also seen hit the frontpage here mentioned not wanting to remap terminals at all - I agreed and eventually delivered. He also made sure that I worked out wordwise hotkeys as well.
Also with it being rewritten, several months ago, to use xkeysnail it is also very simple to add additional hotkey remappings to as well.
stty intr ^X
Then ctrl-c will no longer bother you, and your muscle memory will quickly adapt as X is very close to C
By the way, I don't even know if I could paste with control c or control shift c back then. Maybe there was only middle click.
I could try again now and see what happens.