Hacker News new | ask | show | jobs
by Matumio 3 days 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).

1 comments

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

If you are running Emacs, either in the terminal or in graphical mode, pressing Ctrl+C does not generate any interrupt signal, it simply passes the C-c key to Emacs, which is just a general key bind.

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.

Yes, but the old ways were that the terminal interface itself was in charge of translating this keycode to a signal, based on the line discipline of the terminal. It was a consistent behavior across many apps unless they took effort to modify the current terminal line discipline, i.e. put the terminal into a raw mode. And then many apps tried to do something appropriately signal-like when they decided to handle these input characters without signals.
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>