I'm somewhat amazed but mostly amused that the Vim developers care so little about user experience that they continue to ignore that people have trouble with exiting their tool and refuse to adapt to a more expected convention for exiting it.
Vim's defining feature is the keybinding grammar, so it would no longer be Vim if you changed it.
Modal editing is fantastic: it means you don't need a meta key, or multiple modifier key combinations to do things (for which your wrists will thank you!). It frees up keybindings for different purposes, which is partly how modal editing ends up needing fewer modifier key combinations.
Best thing in editing technology yet.
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.
The default editor in distros could be set to nano or some other reasonably 'windowsy' editor instead. Those who want vi or emacs know how to fix it anyway...
You could say "I'm somewhat amazed but mostly amused that the Git developers care so little about user experience that they continue to ignore that people have trouble with the fact that git command line arguments are an incomprehensible morass of inconsistencies un-righted by overly verbose walls of documentation."
What the two have in common, of course, is that despite being exceptionally beginner-hostile, the tools are massively popular for other reasons. Namely, they are powerful, relatively fast, and they also strongly benefit from cult of personality and network effects.
Not everything has to be easy to use, some things benefit from not being obvious.
That said, as others have pointed out, the vim developers can't really be blamed here as it's just a very hard problem. There isn't a common convention, and vim already goes above and beyond to try and educate users on how to get out. People ending up on this SO question just seem unwilling to read.
Sounds like a distro problem.
macOS is another potential culprit - can't remember the default there.
The problem vim has is that its UI is entirely organized around modes, which makes the "people are terrible at using modal interfaces" problem a hard one for it to cope with.
You may as well expect Porsche to move the 911's engine to the front.
The vast majority of people don't use vim, so this "solution" has already been widely adopted. (Which in turn causes people who like vim to periodically wonder why more people don't use it.)
The problem comes because there are scenarios where you don't have a choice as to which editor to use; if you're shelling into a server with limited privileges, for instance, vi/vim may be the only even remotely modern editor available. So lots of people find themselves forced to use it, and these are the people for whom the Stack Overflow thread is useful.
Like... nano? Or pico? All quite broadly available, and easy as dirt to use. You can even use them to work with `visudo`, one of the few times where I could imagine you don't have a choice.
Also, if you can edit it remotely over SSH, you can scp it in two directions and use your own favorite editor (assuming that editor doesn't already have something like network editing already built in; most do).
If you "don't have a choice", you're not looking hard enough.
That said, any server admin who for whatever reason allows people to SSH in (shared hosting maybe, university, file sharing) should have nano installed. Anything else is just cruel!:wq
They probably learned how to do that in a Stack Overflow thread as well. No competence necessary.
Do we need to spoon-feed you people the solution for all of your problems?
Use SSHFS to mount your remote file system, and edit your remote files with your fancy, LOCAL, non-vim editor.
That doesn't sound like a reason to change vim, it sounds like a reason to change the configuration of the server to something saner. pico/nano makes sense to me, if the expected users are the kinds that wouldn't know how to exit vim or emacs.
People "terrible at using modal interfaces" should just use another editor.
The problem might lie in other applications indirectly launching VIM, taking for granted the users' familiarity with it.
Not to mention your OS is full of modal interfaces. "Why can't I type?" "You have a menu open." "Why can't I type when my cursor is over this window?" "You have a different window as your focus." "Why doesn't space pause this YouTube video?" "Because play wasn't the last button clicked." "WHY ALL CAPS?" "Check your capslock key."
None of these are examples of modes, at least not as the term is used in the context of user interfaces. (See https://en.wikipedia.org/wiki/Mode_(computer_interface)#Defi... for more information.) Modes hijack the entire behavior of the application until the user switches out of them. Windows and menus aren't modal unless they block all other input until the user deals with them.
On the other hand your last example, the CAPS LOCK key, actually is modal; once it's engaged, everything you input is going to be capitalized until you disengage it. You will also notice that the CAPS LOCK key is a common source of user problems in tasks where capitalization is significant, like entering passwords; and that for this reason there are frequent calls to remove it from the standard keyboard layout.
Ditto the multi window scenario. You have to actively change focus between windows (often between windows in the same application), until which time the application doesn't respond as you expect it to.
Another great example: spreadsheets. You're in one of two modes, editing a cell or moving around cells. Often without great feedback of which mode you're in.
Modal interfaces are everywhere.
They're often not intuitive, but intuitiveness is not the be-all and end-all of interfaces. It's a trade-off.
The problem is you do crontab -e or something similar on a new or foreign system and get into vim and are now stuck.
There's kind of a trend of tools that are bright and shiny, but not actually that good at their main purpose. You hit a plateau. We don't need more of these, we need more tools that are bold enough to be powerful, even if they're at first hard to learn.
so forget about all the people who have used vi for decades?
It might make sense to have a bar at the bottom or top with some of the very very basic commands a new user may need (like quitting) that more experienced users can turn off with a command line option or a config value. (specifically if say you do crontab -e or something similar and had no intention of using vim and are now stuck)
Want to quit vim? How's about:
1- Hit ctrl-z
2- Type "kill -9 %"
3- Hit enter
Result: dead vim. Heck, dead anything that was previously on the foreground.
This works with emacs, vi, nano, and, I guess pretty much everything, since ctrl-z is captured by the shell and never gets sent to the application (I think).
Nor how to open a separate tab session, do a `ps`, and kill that.
It should be shell 101, but it's not.
[0] autocorrect lol of the day: "I'm a vi[rgin]"
____________
[1] As in command and edit modes.
[1] http://wayback.archive-it.org/all/20150203071645/http://cm.b...
It's not like other editors behave much differently than vim. Try for example to get out of an "git log" with CTRL-C. Or figure out what the key combo ^x in nano means as a novice.
VIM is a bad default editor for that reason. But don't blame VIM for being what it is. Rather convince your distro or whatever to set nano as the default, easy to learn, editor.
Which would be?
Doesn't work there, either. Most of those don't even offer advice on how to exit when you hit that combo, do they?
So, how is Ctrl-C the right answer then?
Use nano if that's what you want. There's no reason to fuck up vim for people who actually use it to help the people who don't.
The impact on vim users would be virtually nil whilst also respecting that non-vim users are caused problems. Who is most to blame is not usually the most helpful focus.
> that no actual user of the software has? It's not an iphone, it isn't meant for use by the general public.
You're obviously wrong.
Millions of users of the software have that problem. It is used by the general public. It's irrelevant whether they intended to be users of the software or not. No one decides on a distro based on the default text editor, and some people are still learning how to use nix and won't know to change it right away.
Plus, from vim.org:
> It's not just for programmers, though. Vim is perfect for all kinds of text editing, from composing email to editing configuration files.*
Sounds like vim is for use by the general public to me. It just isn't very good at usability.
>Many of us get dropped into vim by accident.
>> It's not just for programmers, though. Vim is perfect for all kinds of text editing, from composing email to editing configuration files.*
can be used for anything != should be used by everybody
>It is used by the general public.
Laughable.