4 ms·

> 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 "cop

by Matumio 4mo 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).

simiones 4mo ago
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 4mo ago
  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 4mo ago
    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>
  - simiones 4mo ago
    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.
    - saltcured 4mo ago
      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.

by Matumio 4mo ago

simiones 4mo ago

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 4mo ago
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 4mo ago
  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>
- simiones 4mo ago
  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.
  - saltcured 4mo ago
    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.