Hitting Ctrl+C still works, it tells you to type ":quit<Enter>".

Why doesn't it just quit? That's as stupid as Python's

    >>> quit
    Use quit() or Ctrl-D (i.e. EOF) to exit

The software knows perfectly well what I'm trying to do FFS.

Because it's an editor, and if it just quit on me every time I mistyped Ctrl-C just because you can't be bothered to type the right command, I would be quite angry.

My GUI editors quit on me every time I mistype Ctrl+Q. I don't really see the difference.

Since I switch between Mac OS X, Windows, and Linux hosts, accidentally typing ctrl-c when I meant to type cmd-c (copy outside of Terminal) isn't such an infrequent error. I'm thankful that ctrl-c isn't mapped to quit without saving.

Well, and my GUI editors don't respond to single-letter commands. It would violate my expectations of their UIs if they did. Similarly, in vim, I expect ctrl+q to send an XON signal to my terminal emulator...not to quit my editor.

They're different programs with different UI conventions. I don't expect them to act the same. And I especially don't expect vim to change, after having 25 years of its own precedent and an additional 16 through vi.

I would think that in both the ^Q and ^C case, the editor in question is capable of prompting "Really exit? (Y/n)" or something to that effect.

Right... I think the point is that this behavior is not preferable.

I do consider that a misfeature, especially since Ctrl+W and Ctrl+A are one key away and often carry commonly-used commands.

I have an entire section of my emacs file devoted to unbinding keys that accidentally close my editor.

So it actually doesn't, it's basically just a hack around the fact that the repl is basically:

    while True:
        print(str(eval(input())))

Case in point:

    >>> x = str(quit)
    >>> x
    'Use quit() or Ctrl-Z plus Return to exit'

I suppose you could implement quit.__str__ as sys.exit(0), if you really wanted to avoid this problem.

Whatever logic currently used to print the 'Use quit() or Ctrl-Z plus Return to exit' message could also... quit the REPL in the first place, right?

I don't program Python much but do its users constantly type "quit" but not actually want to quit such that the REPL special cases this situation?

> Whatever logic currently used to print the 'Use quit() or Ctrl-Z plus Return to exit' message could also... quit the REPL in the first place, right?

That one would probably be somewhat risky actually, that message is the "repr" of the quit object/function, displaying results at the repl invokes repr… but so does printing most containers, so e.g. `vars(__builtins__)` (to get a quick list of the builtins) would also quit the repl, which would be undesirable.

There is no special logic behind it. It just prints the value of the variable with the name "quit", the same way it would print the value of the variable "foo" if you typed "foo".

The repl's basically supposed to help you write a program by matching the behavior of Python itself. What if I've got a variable called "quit" and I want to check its value?

The repl treats it specially because "quit", taken out of the context of the repl, makes sense as something to type in when trying to quit an unfamiliar program, not because actual Python programmers are likely to type it often.

quit is not a piece of repl functionality, it is a python function that will exit the repl when called, with a string representation that gives that message. If I set quit = 1, or if I define my own quit() function, I don't want to have to be continually fighting the repl in order to inspect its value.

Humane programming is something I wish compiler and language builders would do more of

Approximately 50% of the contributors in this thread argue actively against it, so I wouldn't hold my breath ;)

That was not lost on me. They're wrong, and kinda mean TBH, but someday someone will make a pretty good language, with a really helpful compiler/interpreter and will have the viral-fu to get it in use

It's insidiously more malevolent than that, considering how much productivity is wasted.

Plenty of good reasons for ^C not to quit, mostly having to do with the rest of the Vim interface. Off the top of my head, first ^C is for cancelling actions, second ^C is very close to ^V, which is used for block-select, and very close to ^X, which is used for auto-completion, and very close to ^D, which is page-down, and quitting by mistake would be super frustrating.

I think in this case vi's authors (and by extension vim's author) have picked the right choice of catering to the actual users, rather than being friendly to people who run the editor by mistake. At least they try to tell you "type :quit and press enter to exit".

In both cases, the program doesn't know what you're trying to do. It knows what you're probably trying to do. That's not enough.

In both cases, this is because there's a race condition:

If you run a command and decide you want to kill it, you use ctrl-c. If the command finishes between you deciding to kill the command and the signal being sent, the "container" process (vim or python) receives the ctrl-c. If it always assumes "what you want" is to exit, you've maybe lost work - edits made or variables populated. Avoiding that is definitely the right call!

You might expect it to quit immediately, but most Vim users don't (for example I have a habit of using Ctrl-C to exit insert mode). When you travel to a foreign country you shouldn't expect everybody to speak your language.

What if you're normally a Windows user and you pressed CTRL+C trying to copy something out of the terminal? You haven't written to disk in a while, and then poof.

Muscle memory can be a real pain some times.

I got dropped into vim the other day (fortunately I used to be a vim user) unexpectedly.

Had switched from Ubuntu to Fedora and it turns out that vim was the default git editor not nano (until I switched it anyway).