for emacs to gain mindshare, it needs to meet people where they are, not where emacs was 30 yrs ago.
of course, emacs does not work reliably in windows, so that is another issue
for emacs to gain mindshare, it needs to meet people where they are, not where emacs was 30 yrs ago.
of course, emacs does not work reliably in windows, so that is another issue
No, it's the same issue. In a Linux shell (say, bash or fish) ctrl-c is not "copy" but "terminate program". Most emacs editing keys (copy-paste, motion) work in the shell as they do in emacs, at least in fish and bash (and probably other places in Linux).
It made sense that interrupt in Emacs could get into a controlled state of receiving the next command. It's a little bit like the SAK (secure attention key) concept, as seen with Windows use of ctrl-alt-del.
Edit: Ironically, as a long-term emacs user, I don't really remember any commands that start with ctrl-c! For me, the most common sequences start with ctrl-X or meta-X. Or the prefix search commands ctrl-S and ctrl-R.
Now, C-c in particular is the key stroke which non-core modes are recommended to use for their key binds (for example, sgml-mode uses C-c as a prefix for all of its commands, e.g. C-c C-f for sgml-skip-tag-forward, C-c C-b for sgml-skip-tag-backward, etc). Running `killall -SIGINT emacs` will not be interpreted as a C-c key being hit in emacs, it will just cause emacs to quit.
The same thing is true for other terminal based programs, like vi. Pressing Ctrl+C in vi does not generate an interrupt signal, it just passes this key combo to vi to do with as it pleases.