4 ms·
> 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 "Int
by quesera 4y ago
> 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)".
- jcelerier 4y agoWhat a something means is defined by how many people use it for a given definition. If tomorrow half the earth starts saying "fork" for knife then that is what "fork" will mean - the ratio for ctrl-c meaning copy vs its Unix meaning is even stronger. Being there first has exactly zero importance
- quesera 4y ago> What a something means is defined by how many people use it for a given definition. 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.
- fnordpiglet 4y agoSometimes standards emerge rather than from formal bodies but by broad experience and consensus. The Microsoft operating systems dominated human experience for decades. I’m sorry that other systems did different things, but on the basis of cumulative human experience, these key bindings are in fact standard. Any variance, no matter how ideologically pure, is opposed to the collective human experience of cut and paste key bindings. Why do that to people? Because of some market outcomes from 30 years ago didn’t go the way you prefer so we should impose confusing experiences on everyone? That’s audacious.
- quesera 4y agoThis is silly. 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.
- torstenvl 4y ago> Ctrl-C for copy is not a standard . . . and it cannot become so, due to the preexisting meaning. 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?
- quesera 4y agoIt is my contention that, in a terminal environment, any attempts to redefine the standard meaning of Ctrl-Q as something other than XON will fail because it is impossible to do so consistently. 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!
- torstenvl 4y agoThank you for confirming.
- 4y ago
- Kamq 4y agoExactly, and this is a generally posix terminal application (windows only under cygwin/wsl). Let's ask users of the unix style terminal what ctrl-c means there.
- fnordpiglet 4y agoBut a text editor is not an interactive operating system repl for controlling jobs and files. Why would it matter? I don’t think the key bindings in Kerbal Space Program have much to do with the key bindings in Factorio either.
- MobiusHorizons 4y agoBecause it runs in a terminal, and that’s how programs are supposed to behave when stdin is a tty.
- fnordpiglet 4y agoNo, that’s how certain type of OS launched jobs behave, specifically pipes or daemons in foreground. There have always been programs that have very different behavior in their interaction that do not honor the job control binding. Emacs comes to mind, almost all Usenet readers, etc.
- amadeuspagel 4y agoEmacs is a terrific example here, and of course vim as well. "How to exit vim?" wouldn't be such a meme question if you could do it with Ctrl-C.
- quesera 4y agoEmacs does nothing when you press Ctrl-C. Try it. Then do it again. It isn't "copy"! 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 Vim
- kazinator 4y ago> What a something means is defined by how many people use it for a given definition Ctrl-C means interrupt to everyone in Unix, since the dawn of Unix.
- alpaca128 4y ago> Ctrl-C has meant "Interrupt" since the 1960s. 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.
- quesera 4y agossh is a transport method. Of course it should not interpret in-line application commands. 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.
- amadeuspagel 4y ago> 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.
- quesera 4y ago> 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.
- pjmlp 4y agoBack in those days Mac OS didn't had a terminal, unless for developers using MPW.
- quesera 4y agoBut Mac OS (Xerox PARC) invented cut/copy/paste/undo, and defined the keys to be Cmd-X/C/V/Z. Instead of trodding upon well-established conventions (including those in use in the Apple II-][-// world), they made their own new ones. 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.
- otikik 4y agoI am a heavy terminal user and I am fine with an editor using ctrl c,x,v and for copy,cut,paste. It isn’t “Blasphemy”, there’s plenty of ways to send a signal to a process if you really need that. It’s an editor. Let’s chill a bit.