> 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).

▲

simiones 6 hours ago | parent [-]

Ctrl-C in Emacs is not "terminate program", it is "start of user command", in most modes. Similarly, even in vi/vim, Ctrl-C does something completely different. So this has nothing to do with the terminal whatsoever.

▲

saltcured 4 hours ago | parent [-]

It's an even more basic Unix affordance, that terminals had a key-binding that generated the interrupt signal, and programs could define useful behaviors that commenced upon receipt of interrupt.

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.

	▲	skydhash 4 hours ago \| parent [-]
		Ctrl-c is mostly for modes, not core emacs. Org-mode and gnus have a lot of bindings. But there’s a convention that ctrl-c then <character> are not to be bound. There needs to be a modifier for <character>