Hacker News new | past | comments | ask | show | jobs | submit login

Control-C has been the ‘break’ key for serial consoles since the 1970s so it is the GUI cut and paste that is new.



I believe that is true, but that doesn't automatically make it the sensible choice for ctrl-c


You'd have to break behaviour for all experienced sysadmins then. I don't see why these users are "legacy", when terminals exist exactly for this kind of purpose. Personally I use Ctrl-C for SIGINT far more than I use Ctrl-Shift-C for copy. So why would I want it the other way round?

And what about Ctrl-Z, Ctrl-D and Ctrl-A, all of which I use regularly? Are you going to require these to have Shift added too? What about all the other control codes? Or are you going to be inconsistent and have special behaviour just for C, X and V?

Whichever way, you'd end up with a configuration setting for your claimed "legacy" behaviour. Then there will be two ways to do things, and that'll be confusing whenever someone has to use someone else's terminal, or give someone instructions to help them.


they're legacy by definition of being pre-existing users. if you're used to that setting, you have a legacy of using it

a new user would not expect git bash to have shift-insert as paste, and that is an unnecessary inconvenience, especially considering that git bash is more the rule than the exception in doing this, with a variety of different routes to the same goal

I think they should be opt-in instead of opt-out or forced. standards save time and energy and they should be respected, especially in something so common, especially if the legacy alternatives are so easily maintained


>> standards save time and energy and they should be respected, especially in something so common, especially if the legacy alternatives are so easily maintained

In a terminal the standard is for Ctrl-C to send SIGINT to the foreground process.

If a terminal emulator did not follow this standard behavior, I would not use it.


You can also issue the relevant stty command to remap the interrupt control key in your .bashrc.

Or configure or modify your terminal to remap the keys before it gets to the TTY driver.


https://en.wikipedia.org/wiki/IBM_Common_User_Access <- origin of C-c/C-v and other shortcuts for copy/paste and related activities.

The date on that publication is 1987. So what you're asking for is, why didn't people in the 1970s anticipate this future de facto standard?


what an odd assumption

I'm suggesting that the de facto standard behaviour should be respected, or made opt-out. what people did or thought in the 1970s isn't relevant to that


The standard behavior, is for C-c to send SIGTERM. You’re advocating to change that standard to a new standard. Why should your preference take priority over decades of standardization? Shouldn’t the old standard be respected, or made opt-out?


I don't believe so. why? because those shortcuts are the standard across practically every program that is not a terminal


> because those shortcuts are the standard across practically every program that is not a terminal.

Shift + insert works far more ubiquitously.

C-c doesn't work on electron apps for me.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: