Ctrl-X to exit is not intuitive. That's used to cut text almost everywhere. Instead, use Ctrl-Q (quit).
It's been 35 years since CUA[1]. Another terminal editor, micro[2], already adopted these conventions—Ctrl-C to copy, Ctrl-X to cut, Ctrl-V to paste—other terminal editors should as well.
Blasphemy. Especially in a terminal environment.
Ctrl-C has meant "Interrupt" since the 1960s.
IBM and MSFT decided to bastardize the Macintosh's Cmd-C into Ctrl-C for "Copy", but this is a historical tragedy that should not be propagated.
Ctrl-S means "XOFF ~(Pause output)", and Ctrl-Q means "XON ~(Resume output)".
Only in context.
I don't really care what Windows people do with their Ctrl keys.
But using Ctrl-C for copy in a terminal environment (from TOPS-20 to Linux and macOS, and whatever MSFT calls its captive Linux env) is wrong.
It is wrong because Ctrl-C already performs another critical (more important) system function. It can't do both, and forking (knifing?) up the UI to have it do different things is a mistake.
Ctrl-C for copy is not a standard in the UNIX/POSIX terminal environment, and it cannot become so, due to the preexisting meaning. Any other usage in that context is wrong and will fail.
Your bias is in your experience too. There may be more of you than there are of me, globally, but your language (UX expectations) is not universal, and will fail in other places.
This is a non-sequitur. Standards change all the time, even things with a preexisting meaning.
I also seriously doubt you believe it yourself. You brought up the example of Ctrl-Q earlier. Is it truly your position that it's not possible for the standard meaning of Ctrl-Q to be something other than XON?
Ctrl-Q does not even reach the application in a standard terminal configuration. It is possible to configure the terminal to allow it, of course, and some existing applications do so.
However, it will not become "standard" because it cannot be ubiquitous, or even common except in certain classes of application.
And what would you do with Ctrl-Q? Quit? Ctrl-C has you covered there (retroactive mnemonic: "Cancel").
So don't bother trying to redefine Ctrl-C either, you will only cause unnecessary pain for your users, and adoption hassles for your software.
Windows users are not your target market for terminal-based software. So instead of inventing your own creole Esperanto patois, just speak the local language!
Between bogarting the Control key and flipping the directory separator, Windows should use the motto "We're different just because we can be."
Let's ask users of the unix style terminal what ctrl-c means there.
And when was the last time you tried pressing Ctrl-C in vim?
It's evidently been many years.
Here, I'll save you a few keystrokes:
vim /tmp/sigh
^C
Type :qa! and press <Enter> to abandon all changes and exit VimVim added Ctrl-C messaging because people complained about remembering :q.
Anyone complaining about that today is just drafting off the historic humor and making a show of their ongoing ignorance.
Line oriented interactions ^C as break maybe makes sense. In a screen oriented termcap application I don’t think you are right.
(Note that "Break" is another key sequence entirely. If someone asks you to send a Break, you would not send Ctrl-C.)
I am arguing that setting Ctrl-C to any other action (esp a very common action like Copy) in a terminal environment application of any kind, e.g. a screen-oriented editor, is a bad idea.
After loaded, some executables install their own handlers for Ctrl-C. None of them are copy/paste.
Emacs does nothing on a single Ctrl-C, and a double Ctrl-C evokes a "this does nothing" message. Vim prints a "how to quit" message.
I'm sure you can find an example of a terminal based program that does something less reasonable with Ctrl-C. I'm not sure you can find an example that treats Ctrl-C as copy. But you could certainly write one. You should expect people to complain if you do!
By the way, Ctrl-D does not close the terminal either. It tells the shell that you're finished sending input, which means it has no more work to do and should exit. If you have jobs running in the background, it will warn you first (default config). If the shell exits, and it was the only thing running in the terminal, the terminal may then decide to close itself. Some do, some do not.
Back to Ctrl-C though, using your example of top as a screen-oriented program: when you press Ctrl-C in top, it interprets the input as Interrupt, and ... exits! Just like a user in a terminal environment would expect. :)
You are right, it does exit on ^C. I picked it as an example of something that seems compliant but doesn’t actually behave like a line oriented program as a screen oriented program.
stdin is a different thing in a screen-oriented program than a line-oriented one, yes. Screen-oriented typically operates on characters not strings, roughly.
Closing stdin in a screen-oriented program doesn't really have a meaningful interpretation.
But if you'd like an example of a screen-oriented program that exits on Ctrl-D, I can offer musikcube. Not very well-known perhaps (though it's a great music player), and to be fair I consider the Ctrl-D behavior to be a UX oddity, however harmless.
Because that's the intuitive behavior in the terminal. The other programs you listed launch their own window and are obviously a different context.
Even things like vim and emacs (the foundational terminal editors) will give you a message that ctrl+c doesn't work the way you expect (admittedly in emacs you have to hit it repeatedly), because it's so expected that it's assumed that's what you're going to try.
You can have different behavior with ctrl + c, but it's going to be confusing enough that you're also going to have to print a message for everyone else.
Ctrl-C means interrupt to everyone in Unix, since the dawn of Unix.
Terminal != Terminal application
Would you really want your SSH connection or editor session with unsaved changes just exit after pressing one key combination? Interactive applications have different requirements than a commandline with much more limited inputs. There's no reason to be against Ctrl-C for copy in a text editor.
xterm should also not respond to an application command.
An editor is an application, and it should respond. You can choose to handle interrupts instead of immediately exiting of course. But the meaning is intact.
A well-behaved application in a POSIX environment will not fight the well-established conventions. There are many reasons for this, but the two most obvious are:
- The implementation of the expected behavior might be outside of your control. Try pressing Ctrl-S in some terminals, and you will find that it does not reach the application because flow control is handled at a lower layer. By convention.
- Just don't abuse your users! If they get accustomed to using the non-standard Ctrl-C for copy, and then use that same action in another application, they might lose data and it will be your fault.
That ship has sailed. Today, most people are accustomed to using Ctrl-C to copy.
That is not true, in the relevant context: that within which this software is released.
Microsoft didn't make their own keyboards (at the time), so was at a bit of a disadvantage when they copied the functionality from Apple. They didn't have to choose Ctrl, but they apparently decided that multitasking and job control were the domain of non-personal computers and not their problem.
Plus it's even used in that one famous Matrix scene[1] where he is trying to close out of whatever he sees open on his computer. ;)
[1]: https://youtu.be/sjoad6gcRzs?t=31 (31 ~ 50s)
It’s no IDE, but it never claimed it was either. It doesn’t require a manual, as even the shortcuts are shown at the bottom of the screen for reference. And it includes syntax highlighting, tab handling, and basic cut/copy/paste handling.
What is it you’re missing from a standard text editor?