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 works in a certain way. Once you understand it, the mechanism for exiting fits in just with the rest of the patterns. Why should they create a special case for exiting versus other operations? "Why is it so hard to search? Use ctrl-f instead of /" "Why is it so hard to cut and paste?" "why is it so hard to move the cursor?" You'd have a different editor if you changed the keybindings.
Vim's defining feature is the keybinding grammar, so it would no longer be Vim if you changed it.
vi's defining characteristic, which vim inherits, is that it is _modal_. That means that it has modes, like input mode (where what you type is added to the file), and command mode (where what you type are commands to the editor).
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.
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.
> developers are often dropped into Vim from a git command or another situation where they didn’t expect to be, and they run into it infrequently enough to forget how they solved it last time.
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
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.
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.
> 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.
> 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.
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.
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
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.
Wait, this is how I got so stuck my first time in vim! It sets you up for a whole string of problems in a row:
- 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.
Weelll. The problem is that the "quit" command has an insert mode key in it. So it's quite possible to get stuck like a poster above says- enter macro recording, then insert mode, then write the letter "t".
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
See all that whitespace? It's very hard to think the colon goes to the "Type" bit.
So you can get stuck in a dubm situation but it's not terribly easy.
See all that whitespace? It's very hard to think the colon goes to the "Type" bit.
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.
Alright, but if we're being so scholastic it should be said that you can misinterpret any set of instructions and in this case, squinting at the command line a couple of times to make sure you got the command right is all it should take you to get it right.
Cute, but no. When you enter insert mode, the "welcome screen" disappears. So if you can see the instruction telling you to type ':quit', then typing :quit will work.
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.
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
disappears as soon as you enter insert mode (or really interact with Vim at all). If you're in insert mode, you don't see this. So if you see this, typing :quit will work.
Of course, yes. The above commenter mentioned insert mode and ctrl+c which is why I was missing that you particularly were talking about this one screen.
And worse vim is often the default EDITOR or software's fallback in case no EDITOR is set, so you get dropped into a vim edition buffer seemingly randomly.
I'm pretty sure that I've never seen any OS/Linux distribution set default EDITOR to vim. If EDITOR is set to vim, then someone must intentionally did that.
Right. Many programs react to an unset EDITOR variable by assuming vi though. This makes sense, of course, as virtually all systems are going to have some implementation of vi installed. Even the almighty ed tends to be missing from the default install of some recent Linux distributions.
Maybe someone should file a bug to them? I don't think vim is a sane default value for EDITOR, but I have no idea whether there's any sane alternative on Windows.
Coming from the Windows world, I am happy that Ctrl+C doesn't make assumptions and quit. Imagine attempting to copy something and having your file close without warning.
Ironically, in vim, where the terminal is in non-canonical input mode when vim is in the foreground, it is not keyboard interrupt. (Nor is it in most modern shells, which also use non-canonical input mode in their command line editing mechanisms.)
Yep. Apple got this one right with the Cmd key. Much saner than the context-dependent hijacking of the control key with its long-established conventional usage.
I don't particularly like vi, but as a intermittent user for 20 years, I don't like it to be changed just because a few junior front end developers (ok a million) think it's hard to use.
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...
As a sysadmin, this drives me crazy. I log into a lot of systems I didn't set up, and then I press the key at the command prompt to bring it up in an editor, or invoke something that uses an interactive editor, and its nano. I have to exit it, export EDITOR=vi and do it again. I don't even like vi as a standard editor. I just expect the system default of vi, and nano is painfully underpowered. I'd even adapt to it running emacs, but it's like getting a nerf hammer every time you need a real one when the system pulls up nano by default.
Or as an emacs user, we deal with a lot of weirdness by modern standards. But when someone asks for a random change, it's more a matter of, "sure, knock yourself out."
One could easily relate this to burkaman's comment in this thread on the most viewed question (how to undo a git commit).
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.
Vim has a steep learning curve and making that one thing easier isn't going to make that curve any easier to climb. Powerful tools require documentation and looking up how to quit is the first task of many to use any of vim's power.
Not everything has to be easy to use, some things benefit from not being obvious.
I think this is a poor argument. If it's the one singular thing that's frustrating this many users, that's a reason to focus on particular on fixing it somehow. You also need to take into account that most users encountering this problem are not deliberate vim learners: they ended up in vim by accident.
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.
There is a common convention, though, which is: don't use modal interfaces, modal interfaces are bad.
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.
Modal interfaces are bad; yet it's what differentiates Vim from everything else, and thousands of people actively enjoy using Vim.
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."
> 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."
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.
How is having an open menu that blocks input NOT a mode? Using your arrow keys will move menu items, enter will select menu items, letters will also often switch menu items attempting to find a menu item with that letter, and getting out of it requires additional clicks or hitting escape.
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.
> If you took the modal interface away from vim, you wouldn't have vim anymore. If you don't want a modal interface, don't use vim.
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.
> you don't have a choice as to which editor to use
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.
> 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.
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.
SSHing into a server implies a basic level of technical competence. The user presumably already knows cd, mv, ls, and family. Why would expecting the user to know a touch of VIM be out of place?
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
It's maybe impossible to create a tool that's relatively small, intuitive, and for experts. Vim is relatively small and for experts.
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.
> "refuse to adapt to a more expected convention for exiting it."
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)
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).
Actually, no. vim runs with the terminal in non-canonical input mode. Control+Z results in a SUB character being sent to vim. vim, in turn, knows to suspend itself when it receives that character (in visual or normal mode).
No, applications can and do trap either ^z or the signal it generates (not sure which). I'm a vi user [0] but I'm pretty sure emacs requires ^z^z to STOP.
emacs stops on a single ^z. You can trap it based on SIGTSTP though (Terminal SToP, a distinct signal from SIGSTOP, which I don't think can be trapped).
The GUI version can be exited from in the same way as any other GUI application. If run from the command line, there is no standard way to exit (nano? emacs? joe?)
For gvim, the X works as expected but what would be a more expected convention from exiting a cl text editor be? Most long running cli tools people are used to are read only and have just a few keys for different views and they tend to use 'q' or 'Esc', any single key isn't an option for a text editor. If they're in normal mode, Ctrl-c does give the message "Type :quit<Enter> to exit Vim" but I'm guessing most people don't notice it or think the ':' isn't part of the what they have to type because they don't now commands start with it, I would change it to "Type ':q<Enter>' to exit Vim". But people tend to accidentally leave normal mode by trying to type other things, so the Ctrl-C message isn't always helpful.
Vim is a modal [1] editor that runs in a console. From those two points onwards you're already a few orders of semantic magnitude away from "more expected convention(s)" so there's really no point trying to fit it into a context it was never meant to fit in the first place.
It’s tremendously important to realize that Vim comes from a VERY long line of text processing utilities that stretches back over a half a century. Vim is the result of constant iteration on a set of design ideas and conventions that predates it. `Q` for `Quit` is one of the oldest Vim commands, tracing its roots all the way back to the `QED` editor of the 1960s[1]. Changing it now would be foolish.
While I love vim, your argument holds no water. By your argument, it's foolish to change anything at any time, because everything traces its roots back to "something."
I think the real problem is that vim is the default editor or people are writing tutorials and using vim. Asking vim devs to break the whole raison d'etre (modality) is kind of ridiculous.
In my opinion the problem is more, that console beginners are told that CTRL+C is a magical bullet that will save them from any obstacles they might encounter in the depths of the cli.
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 pretty much written by one guy, and like Linus he remains consistent in what his creation's user experience should be. VIM is not meant to be easy to learn, it is meant to be easy to use one you've invested in learning it.
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.
the experience of trying to get up-to-speed with the original vim codebase in order to contribute to it is apparently quite awful. So bad that a bunch of folks started neovim. Anyone with the frustration tolerance to go through that gauntlet is unlikely to be very new-user-UX focused.
What interactive terminal programs exit using ^C? Nano doesn't, top doesn't. There is no standard for interactive terminal programs. Furthermore ^C doesn't fit with the rest of vim's control schema, so you wouldn't really be doing anybody any favors in the long run.
> 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.
Perhaps an alternative is a "first run" mode which could do something like ask "did you intend to open vim? Y/N (answering N will close vim)". If you answer Y then you get a lesson in closing vim, if N then you always get the "first-run" mode until you answer Y?
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.
