It literally everytime you boot the first screen tells you how to quit and get help. So..read the screen that comes up Everytime? If you try Ctrl c it tells you it's :q.
So the first screen doesn't help in this situation
The sort of developers who get stuck in Vim are not the ones who are using it intentionally
>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
while True:
print(str(eval(input())))
>>> x = str(quit)
>>> x
'Use quit() or Ctrl-Z plus Return to exit'
It does, it just does not care.
> it's basically just a hack around the fact that the repl is basically:
I know what a REPL is. Here's an idea: it's not difficult to add an exit special case to the REPL.
> Case in point:
Case in point: the developers added a "help text" to tell users to go fuck themselves, knowing exactly what users wanted to do and refusing to do it. quit's repr didn't appear by magic, it was put there, knowingly, by people who understood exactly what they were doing.
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?
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.
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.
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.
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!
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".
Muscle memory can be a real pain some times.
Had switched from Ubuntu to Fedora and it turns out that vim was the default git editor not nano (until I switched it anyway).
me: Hit escape first, then :q
dev: Oh, then why doesn't say escape then :q
me: welp
It happens because people don't what they are doing. You assume that they hit ctrl+c, then immediately type :quit, but if they did, then they wouldn't be Googling it. They did something between trying to exit and quit that got them into a different mode.
What I'm saying is the screen that says
VIM - Vi IMproved
version 8.0.567
by Bram Moolenaar et al.
Vim is open source and freely distributable
Sponsor Vim development!
type :help sponsor<Enter> for information
type :q<Enter> to exit
type :help<Enter> or <F1> for on-line help
type :help macvim<Enter> for MacVim help
"Type: quit<enter> to exit Vim"
Since the colon is used a separator such as I used it above.
Then they type "quit" and enter, which actually put them in insert mode recording "@u", with a 't' sitting in the text area.
- You enter an unfamiliar mode, immediately hit "^c".
- That prompts "Type :quit<enter> to exit Vim".
- You mistakenly type "quit<enter>". So now you're in insert mode with recording, as you said.
- You hit "^c" again, breaking out of insert mode, but you don't get the exit prompt like you did last time - the `recording` message blocks that no matter how much you hit "^c".
- Without the reference message to find your mistake, you maybe try "quit<enter>" again. 'q' now terminates recording, 'u' undoes your typing, and 'i' dumps you back into insert mode, leaving you with a text field of 't' again!
- At this point you maybe hit "^c" again. That'll drop you out of insert, but with text in the field vim no longer prompts you to quit. If you enter "^c" again it will prompt you, but you tried that during recording mode and it did nothing, so you don't expect aimless repetition to help anything!
At this point, you give up, google "quit vim" and discover that the colon was important. I'm pretty sure this madness if what I did the first time git for windows popped open vim as the default editor.
The only way the above would work as suggested is if the person hit an insert mode key first after having typed Ctrl+C.
On the other hand that only happens if you type "quit" without the colon and the message makes it very clear that the colon is part of the text you must enter:
Type :quit<Enter> to exit Vim
So you can get stuck in a dubm situation but it's not terribly easy.
Except, logically, why would they bother to specially call out <Enter>, a whitespace character, but not the spaces as well if they intended the user to type them?
I can't think of any obvious, safe way to display text that a user should type that isn't subject to possible misinterpretation in the single line of output available.
If nano were the editor you end up in, you would have the same problem.