I once helped organize talks at my school, and helped with bringing Richard Stallman to give a talk one time. I was a vim user, but I did a little bit of prep and refreshed my emacs memory etc. So we're setting up the room for the talk, and we're talking a bit, and some people start to arrive. He asks one if they've ever used emacs, she says no, so I said, "we should start an emacs tutorial here, we can teach everyone about things like C-x C-c, and stuff". I just blurted out the only thing I had remembered recently. He turned a cold shoulder to me, I suppose thinking that I had insulted him directly. I ran out to Google what I had said, and then felt terrible about it, but it was too late. That's my remembering how to quit emacs story.
A MIDI foot controller isn't a musical keyboard (though such things do exist, mimicing organ pedals). It's used for MIDI program changes. I have a MIDI programmable guitar pre-amp, and so in combination with this pedal, I have access to various amp settings just by stepping on various buttons.
My anecdotal experience has been that no matter how many times I'm told how to exit Emacs I can't remember but every developer I have taught '<esc>:wq' to has remembered it after one or two times telling them what it is.
C-x C-e evaluates the Emacs Lisp expression before the point. This gives the same result as the much more obvious M-x kill-emacs, but with the added fun of writing and executing Lisp directly in whatever buffer you're in. So to close the editor, we've written some code in a weird ancient language into some random text file, fired up an interpreter that's probably so portable you can run it on a 1980s toaster, and executed an expression which we had to make sure was wrapped in those vile parentheses everyone loves to hate.
Straightforward.
But I just had to explain my own joke, so I'll go wallow in shame for the rest of the day. :(
Emacs is definitely difficult to exit from. The difference is emacs usually isn't the default/fallback EDITOR on the system, so you rarely get dropped into it unknowingly/unexpectedly.
Also: Emacs is rarely if ever used in the terminal today, and exiting it through the standard desktop protocol ([X], Ctrl-[Shift]-Q, Alt+F4, ...) always works.
We get so many people using it in terminals in #emacs. Obviously there's no way to know how many people are not using it in a terminal because they won't be asking GUI-specific questions. I and a few others do try to discourage the terminal users and nudge them towards the GUI which is more featureful, but some people really want to use a terminal at all costs.
I don't think that's true. System administrators will happily use it in a terminal. I'd often deliberately run emacs -nw when something requires a quick edit and the GUI would be imposing.
I use emacs in a terminal all the time (usually in a tmux session, actually). That's how I learned it (in pre-GUI days) and so it feels pretty natural. I never use the mouse with emacs, even in a GUI session.
Note that GUI emacs doesn't mean using a mouse. I use GUI emacs but almost never interact with it with a mouse, I just have a server-enabled emacs running fullscreen in one of my virtual desktops.
It's too easy to hit accidentally, though. I got burned by it a few times, so I eventually unbound the command. I now use M-x kill-emacs when I want to quit (very rarely, anyway).
I'll first admit I'm a worshiper of the Church of Emacs.
I told the trying to exit vi joke for years until someone pointed out to me that C-x C-c was equally if not more obscure. It was a part of me because that was the first thing I ever learned about Emacs. Just like :wq was the first thing I ever learned about vi.
Now, I think the fact that people seem to have more difficulty exiting vi is because vi is very likely the fallback for $VISUAL/$EDITOR, and hence much more likely to be trapped in by accident when unprepared.
There has been a resurgence of use since the popularity of Spacemacs, and I know several of my peers around my age (20) who use Emacs, including myself.
Is there a valid reason to do this in the first place?
> git push origin -f
No standard way to undo that. Only do it if you must, and you absolutely do what's going to happen. Always do a "got remote update" immediately before the force-push and double-check that the remote branch points to what you expect.
As a general rule, "--force" is short for "you better be prepared to deal with the consequences".
Pretty sure I've got the command down by now, but it's embarassing how many times I forgot the exact syntax. It was especially bad before the "--delete" syntax was introduced.
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.
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
> 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.
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
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.
> 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.
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.
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!
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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?)
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.
> 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.
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
> 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.
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.
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.
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.
> 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.
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.
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.
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).
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).
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).
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.
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...
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."
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.
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.
> "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)
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.
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."
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.
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.
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.
Because your keyboard is stuck on permanent caps lock and you cannot remember the alternative to ':wq' which you cannot enter due to the perma-caps input device that requires a reboot to become a keyboard again.
If you use Synergy then this happens and a reboot can be easier if you are stuck.
In theory you really could forget 'ZZ', I nearly forgot '=aB' for some reason recently, this '=aB' to indent is only really known in muscle memory and the actual '=aB' text is entered and gone quickly from the bottom of the screen, so never seen, merely memorised as muscle memory, not a written or vebalised thing.
Add in the bonus confusion that you may not have even been trying to run vim, and in fact may not know what it is (hey, everyone's a beginner some time), but have landed there due to a default $EDITOR value.
[EDIT] also, a typical mid-level computer user's tendency to slap "ESC" when panicked. Ha!
I dunno if it's actually vim or some variation on it, but it is the default on, for example, Arch Linux, although I believe most other distros dropped me into it as well (e.g. git commit / rebase -i).
If there is such a thing as user hostile in the world of CLI tools, then dropping the user unannounced into vi with some open buffer most definitely counts as user hostile.
If vim opens and that's the first thing you try, then it'll work, yeah.
But if you've typed anything, this won't quite work. <ctrl> c will take you out of insert mode, but won't offer any prompt. <ctrl> c again will bring up the quit prompt, but that's not intuitive the way doing it the first time is. And if you type the wrong thing after the first <ctrl> c, you'll break back into insert mode and have to take another run at it.
I remember getting stuck in vim because git bash uses it as a default editor. It happened when I forgot to enter a commit message, which meant that I started typing a commit message and thereby lost the useful prompt when I went to quit.
edit: per another thread, this gets far worse if you don't realize the ':' is active and not a prompt to "type: quit". That error sets off a maze that will never show you the prompt again to find your mistake.
<ctrl>-c is not a vim command. It's a universal terminal command.
<ctrl>-c is how you kill the foreground process in bash, zsh, sh, windows command line, etc...
If you don't know about <ctrl>-c you shouldn't be attempting to use a terminal based editor to begin with. Vim can't be blamed for people not knowing how to use a terminal.
If you hit ctrl-c then you are no longer in insert mode (ctrl-c acts like esc for some reason), so no, it won't add anything to the buffer and ":q" will get you out.
I don't blame people for being confused though.. I remember getting stuck in vim all the time back in the day because of a default $EDITOR value.
On the Mac, the escape key has been used forever in dialogs as a surrogate for the Cancel button or for dismissing dialogs where the results are non-destructive.
Not that it entirely matters, but those country/prog. language stats are useless since they don't normalise to site-wide traffic (or at least they don't seem indicate they do).
Anecdotally, would get stuck in Vim having thought that the override command was :!q instead of :q!...
I saw the bumper sticker ":w saves" and thought, to myself I wonder how many people "get" that.
I suggested a long time ago that vi/vim bind ^C to exit. It currently is equivalent to 'esc' (it puts you into command mode if you aren't there and types the message "type :quit<Enter> to exit Vim". I'd much rather it popped up 'exit vim? y/n?' and the next key would determine if you exited or not.
That looks more like emacs behavior though, vim rarely (never?) prompts the user for anything. You enter a command, you get a reaction (either an action like quits vim, or a message indicating something happened) -- which I personally prefer much more than getting annoying prompts.
It has closer things to prompts. Try editing a file when the last time around you terminated vim without giving it a chance to clean up its .*.swp file. (-:
Actually you get a prompt when you try to save a file that has been modified in a different session or when you switch to a similarly modified buffer. But those are pretty reasonable and don't happen that often.
I'd vote against that. I use ^C as the best "esc-replacement-without-straying-far-from-the-home-row" that works in every install, every emulator and every international keyboard.
Hah. Back in the old days, when I didn't have a second computer to look up help online, I just powered my Linux PC off if I accidentally got trapped in vim. Later on, I'd just close my PuTTy session.
Then I finally took a little bit of time to learn vim.
Haha. I survived using vim JUST knowing Esc and :ws for years~.
I was in a hurry to learn Linux and knowing vim was you know required. So I just learned the most basic in vim. I don't want to think about how much time of my life I wasted because I didn't know more about vim. Classic lesson about technical debt costing time/money over long term...
I can still remember sitting at a VT-220 in the college computer lab with my first Unix account (on a MIPS DECstation of all things), running emacs[1], getting stuck, and then sheepishly having to yank the power on the terminal to fix things.
[1] Would have been emacs 18.something at the time. Not sure if that predates the built-in tutorial or if I just missed it. I remember running the tutorial not long thereafter on a proper workstation where I felt comfortable I could close the window.
(Attribution is questionable, but as a geezer I feel the need to make sure the younger generations at least are familiar with this:)
ed is the standard text editor
Let's look at a typical novice's session with the mighty ed:
golem> ed
?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?
---
Note the consistent user interface and error reportage. Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity.
(As a geezer, I also have to say I really am impressed with ed in some ways, and you should never be afraid to try it when you have a specific and known edit you want to do.)
"When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a “viitor”. Not a “emacsitor”. Those aren't even WORDS!!!! ED! ED! ED IS THE STANDARD!!!"
Using vi/vim lets one enter a secret dark corner of programmer society.
Memorize vi keystrokes is knowing the secret handshakes.
Able to Exit vim is finding the door to enlightenment.
If vi comes with an easy "back" button like all browsers, no-one will learn it. One needs to be trapped inside for a while to feel the power of the dark side.
Yes it is, if you are coming from a GUI life, start using the shell for the first time, and suddenly get thrown into some unnamed editor by git. :P
It breaks about every convention on editors and discoverability that you're used to.
Start GNU nano. It puts me in a position where typing edits the file I opened. It shows me the name of the program. It shows some keyboard shortcuts for interacting with the program. (Though for beginners the ^X syntax isn't obvious either).
Vim, doesn't give me any of that. I infrequently use vim and I still tend to open a file and start typing without hitting i first, because it's behaviour that's inconsistent with every single other editor I have ever used.
My worst memories of starting out with programming is doing a git merge or pull, then before the command was done, I'd start typing git push or... and then I got stuck in insert mode. This was after I had learned that :q och :wq! did the job, and I could not for the life of me figure out how to get out of insert mode.
Or because every other editor you've had is inconsistent with Vim. It is dumb if people are being dumped there by Git. I guess if you try to use it and get stuck it is a lot easier to escape than if someone gets dumped there without even knowing where they are.
I find that with a specific and known edit, it's far easier to do using sed and awk. In particular awk Has better power-to-weight ratio at traditional text processing. I think typical awk scripts could very well be shorter than the equivalent python scripts that do the same thing.
I have written hundred+ line awk programs. For stream text editing it is excellent at what it does and it's install base is huge. Rarely do I encounter a *nix machine without it on there.
Perl & Python are also installed on most UNIX machines I've seen. I know Perl was invented to address weaknesses with Awk. I use all 3 to some degree, but is there a reason you like Awk?
The pattern -> action format of awk is really nice for simple apps, it's a built in for loop + switch statement that reads from stdin. It's also simple to change what the record/column seperators are, so it can handle some quite complex data shapes with zero code.
Awk and python don't deal with stdin/stdout quite as nice (AFAIK) and there is always the temptation to do too much with them.
As an example, the other day I wrote a DSL in awk, it takes a mostly CSV file in and outputs sql commands. If you did it in python you could run the sql directly, but the awk stdio version makes it easier to combine as needed. If I want to run the generated sql I can pipe that to the sql cli client, if I need to hand it to QA I can just pipe to a file etc.
Neat, will have to look into that. I think Perl might have a command line switch with similar behavior that runs your command across every line of whatever you pipe to it, but that might not be what you're saying.
yjftsjthsd-h, I'm curious so I looked it up but couldn't find anything. AFAIK POSIX only specifies operating system behavior and doesn't specify any actual apps but I could be wrong there. In any case, the rise of containerization has brought many nano Linux distributions that often have even fewer packages than even the most minimal distributions of years past.
Excellent point. I'm an Emacs guy by habit, but I'm also a sysadmin, which means I keep a well-stocked repertoire of ex commands ready for when the shit really hits the fan.
After reading lots of similar anecdotes about Ed (Steven Levy's "Hackers" dedicates quite a few words to it), I was quite sure it was pretty much unusable for today's UI patterns, but also morbidly curious about how it might eventually work.
Then I came across "Actually using ed"[1], which did such a great job at explaining how to use the tool that I decided to throw in my 2 cents by submitting an entry to the tldr-pages project[2]. The rendered page looks can be found on [3]. Any feedback welcome!
I recently had to use ed. I wanted to write a handful lines of code, but for that I needed the context that was in the terminal history. I didn't want to keep switching back and for with vi. So I decided this was the time I should learn ed. It did the job it was expected to do, I was not disappointed.
When I told my thesis advisor (in about 2001) that I was looking into backend web development as a career, he gave me a post-it note with the following content:
chmod 0644 is indeed bad advice in ~/.netrc. Similarly, [Esc] :wq is not too helpful at a bash prompt. If you don't know the difference you're not yet ready for the magic post-it note.
My point is that if you don't understand what chmod 0644 does, you probably shouldn't use it as general advice. chmod 0640 would be better general advice, but it's not a fix-all.
Ditto `:wq`. If you're in vim, and you don't know how to exit, you probably don't want the random keypresses you made while trying to figure out how to exit to be written to the file. Another case where an alternate version might be better: [ESC]:q! nano <file>
Not sure if is there is something more subtle in the note but around 2001 (or even later until today) chmod -R 777 was pretty popular advice to solve all kinds of 'problems'. Usally 0644 is a sane default for web stuff.
Yep, that's exactly what he meant: Here's how to get out of vi when you get stuck there, and here's how to undo the stupid thing you just did to try make your website work. For web stuff you usually do want 0644, or 0664 if the files are owned by your user account and not apache.
Ugh, these types of editors drive me batty. Why can't it just be easy to quit? Why, why?! If I absolutely must use an editor in the terminal I use nano.
> It looks like developers in Ukraine, Turkey and Indonesia are getting stuck in Vim quite a bit: it makes up a larger portion of their Vim questions than in any other country. In contrast, in China, Korea and Japan the fraction going to this question is a tenth smaller.
From my experience, people at least from Korea are very likely to develop on windows, even when targeting linux or even embedded linux.
You can tell from the msdos line endings and comments in Korean that are in a weird multi byte encoding that I could not make vim display correctly. I think they use some sort of sftp synchronization tool like WinSCP when you edit a file remotely.
I read that Windows is really deeply rooted in their IT culture, so much so that banking sites are required to use a special encryption scheme implemented in ActiveX. I can see why that would discourage people to use a different OS for their daily needs, let alone convince corporate IT to support dual boot.
IIRC, they had regulations about banking security that mandated some IE6 ActiveX plugin. They are just now, or just have, coming around to changing that.
That's funny because I feel that exiting vim is easy. On the other hand, exiting from nano is a nightmare and makes no sense to me - To make matters worse, it's difficult to find info online because it's hard to explain nano's confusing interface with keywords. I hate how git made nano the default editor on Ubuntu. Every time I install git, I have to remember to change the configs to use vim as the default.
Actually it's exiting when you have unsaved changes which is confusing, the second prompt that comes up makes no sense to me. Also it shows a caret ^ character to represent the ctrl key which is confusing.
488 comments
[ 4.8 ms ] story [ 436 ms ] threadI once helped organize talks at my school, and helped with bringing Richard Stallman to give a talk one time. I was a vim user, but I did a little bit of prep and refreshed my emacs memory etc. So we're setting up the room for the talk, and we're talking a bit, and some people start to arrive. He asks one if they've ever used emacs, she says no, so I said, "we should start an emacs tutorial here, we can teach everyone about things like C-x C-c, and stuff". I just blurted out the only thing I had remembered recently. He turned a cold shoulder to me, I suppose thinking that I had insulted him directly. I ran out to Google what I had said, and then felt terrible about it, but it was too late. That's my remembering how to quit emacs story.
B. Kernighan: have you ever used Unix?
Student: No.
You: Hey, how about we start a Unix tutorial here; we can learn all about dollar-sign-1, and stuff.
B. Kernighan: * roll eyes *
:)
C-M-handstand-q-footpedal
https://en.wikipedia.org/wiki/Joyboard
It would be terrific, particularly for Lisp development with SLIME.
MIDI foot controller -> USB MIDI interface -> computer -> driver -> user space scriptology ...
What do you think? That would easily give you ten pedals.
I use a 1993 vintage ART Ultrafoot X-15 I got off Craigslist --- for my guitar rig, not a text editor. :)
https://www.google.ca/search?q=ART+Ultrafoot+x-15&tbm=isch
Perhaps, exit-emacs or quit-emacs aliases could be defined.
Overall, both are about as hard to deal with. Vim has a better help message, but it's still difficult to find.
Pretty straightforward.
> Pretty straightforward
If this is a joke, it's totally whooshing over my head right now
Straightforward.
But I just had to explain my own joke, so I'll go wallow in shame for the rest of the day. :(
It's too easy to hit accidentally, though. I got burned by it a few times, so I eventually unbound the command. I now use M-x kill-emacs when I want to quit (very rarely, anyway).
;)
I told the trying to exit vi joke for years until someone pointed out to me that C-x C-c was equally if not more obscure. It was a part of me because that was the first thing I ever learned about Emacs. Just like :wq was the first thing I ever learned about vi.
Now, I think the fact that people seem to have more difficulty exiting vi is because vi is very likely the fallback for $VISUAL/$EDITOR, and hence much more likely to be trapped in by accident when unprepared.
* http://jdebp.eu./Humour/exiting-emacs.html
Middle
Aged
Computer
Scientists.
E.M.A.C.S.
Besides, won't every currently young computer scientist be a middle aged computer scientist soon enough?
You can get the top viewed questions here: http://data.stackexchange.com/stackoverflow/query/53109/ques...
Is there a valid reason to do this in the first place?
> git push origin -f
No standard way to undo that. Only do it if you must, and you absolutely do what's going to happen. Always do a "got remote update" immediately before the force-push and double-check that the remote branch points to what you expect.
As a general rule, "--force" is short for "you better be prepared to deal with the consequences".
Remote reflog contains this info (if enabled).
Of course not all commands would be reversible, especially not plumbing.
EDIT: the replies to this don't get how feature requests work. yes, I could write this basic feature myself. thanks.
A minor usability investment on the part of 1-2 git developers would prevent thousands of hours wasted by newbies and perpetual intermediates (https://blog.codinghorror.com/defending-perpetual-intermedia...).
https://stackoverflow.com/questions/2003505/how-do-i-delete-...
Pretty sure I've got the command down by now, but it's embarassing how many times I forgot the exact syntax. It was especially bad before the "--delete" syntax was introduced.
Though at least now github provides easily access buttons.
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
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
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."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:
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.
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.
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.
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.
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.
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]"
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...
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.
* http://www.texteditors.org/cgi-bin/wiki.pl?T
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)
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.
[1] http://wayback.archive-it.org/all/20150203071645/http://cm.b...
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.
____________
[1] As in command and edit modes.
[1] https://twitter.com/iamdevloper/status/435555976687923200?la...
Because your keyboard is stuck on permanent caps lock and you cannot remember the alternative to ':wq' which you cannot enter due to the perma-caps input device that requires a reboot to become a keyboard again.
If you use Synergy then this happens and a reboot can be easier if you are stuck.
In theory you really could forget 'ZZ', I nearly forgot '=aB' for some reason recently, this '=aB' to indent is only really known in muscle memory and the actual '=aB' text is entered and gone quickly from the bottom of the screen, so never seen, merely memorised as muscle memory, not a written or vebalised thing.
Isn't it just...
[Esc] :wq
...or...
[Esc] :q!
...depending if you want to save the current document or not?
[EDIT] also, a typical mid-level computer user's tendency to slap "ESC" when panicked. Ha!
If there is such a thing as user hostile in the world of CLI tools, then dropping the user unannounced into vi with some open buffer most definitely counts as user hostile.
git rebase -i
For example
Then, the program tells them "Type :quit<Enter> to exit Vim"
And if the user is capable of reading, they shouldn't have any problem.
If they don't know about ctrl-c, they shouldn't be using a terminal editor.
But if you've typed anything, this won't quite work. <ctrl> c will take you out of insert mode, but won't offer any prompt. <ctrl> c again will bring up the quit prompt, but that's not intuitive the way doing it the first time is. And if you type the wrong thing after the first <ctrl> c, you'll break back into insert mode and have to take another run at it.
I remember getting stuck in vim because git bash uses it as a default editor. It happened when I forgot to enter a commit message, which meant that I started typing a commit message and thereby lost the useful prompt when I went to quit.
edit: per another thread, this gets far worse if you don't realize the ':' is active and not a prompt to "type: quit". That error sets off a maze that will never show you the prompt again to find your mistake.
If you try to <ctrl>-c, the program even tells you to use :q
It's just become a meme at this point.
Edit: ah quit foreground process, ignore me
<ctrl>-c is how you kill the foreground process in bash, zsh, sh, windows command line, etc...
If you don't know about <ctrl>-c you shouldn't be attempting to use a terminal based editor to begin with. Vim can't be blamed for people not knowing how to use a terminal.
And then you do and it helpfully adds ":q" to the buffer.
You're still in vim.
I don't blame people for being confused though.. I remember getting stuck in vim all the time back in the day because of a default $EDITOR value.
I love vim and I've used all of those at some point. I'd never pretend there's no learning curve, just that the learning curve is worth it.
[Esc] :x
to save and exit.
Anecdotally, would get stuck in Vim having thought that the override command was :!q instead of :q!...
(vim captures ^Z in input mode)
I suggested a long time ago that vi/vim bind ^C to exit. It currently is equivalent to 'esc' (it puts you into command mode if you aren't there and types the message "type :quit<Enter> to exit Vim". I'd much rather it popped up 'exit vim? y/n?' and the next key would determine if you exited or not.
if people don't notice the "Type :quit<Enter> to exit Vim" message, they also won't see the (Y/N) selection.
so, absolutely nothing gained by making this change, except making things more annoying for people who do know how to use vim.
> E37: No write since last change (add ! to override)
It is prompting you to add a !
https://stackoverflow.com/questions/1019573/save-icon-still-...
Then I finally took a little bit of time to learn vim.
I was in a hurry to learn Linux and knowing vim was you know required. So I just learned the most basic in vim. I don't want to think about how much time of my life I wasted because I didn't know more about vim. Classic lesson about technical debt costing time/money over long term...
[1] Would have been emacs 18.something at the time. Not sure if that predates the built-in tutorial or if I just missed it. I remember running the tutorial not long thereafter on a proper workstation where I felt comfortable I could close the window.
ed is the standard text editor
Let's look at a typical novice's session with the mighty ed:
(As a geezer, I also have to say I really am impressed with ed in some ways, and you should never be afraid to try it when you have a specific and known edit you want to do.)https://www.gnu.org/fun/jokes/ed-msg.txt
Memorize vi keystrokes is knowing the secret handshakes.
Able to Exit vim is finding the door to enlightenment.
If vi comes with an easy "back" button like all browsers, no-one will learn it. One needs to be trapped inside for a while to feel the power of the dark side.
It breaks about every convention on editors and discoverability that you're used to.
Start GNU nano. It puts me in a position where typing edits the file I opened. It shows me the name of the program. It shows some keyboard shortcuts for interacting with the program. (Though for beginners the ^X syntax isn't obvious either).
Vim, doesn't give me any of that. I infrequently use vim and I still tend to open a file and start typing without hitting i first, because it's behaviour that's inconsistent with every single other editor I have ever used.
Fun times.
Awk and python don't deal with stdin/stdout quite as nice (AFAIK) and there is always the temptation to do too much with them.
As an example, the other day I wrote a DSL in awk, it takes a mostly CSV file in and outputs sql commands. If you did it in python you could run the sql directly, but the awk stdio version makes it easier to combine as needed. If I want to run the generated sql I can pipe that to the sql cli client, if I need to hand it to QA I can just pipe to a file etc.
Isn't it posix mandated?
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/aw...
Then I came across "Actually using ed"[1], which did such a great job at explaining how to use the tool that I decided to throw in my 2 cents by submitting an entry to the tldr-pages project[2]. The rendered page looks can be found on [3]. Any feedback welcome!
1. https://sanctum.geek.nz/arabesque/actually-using-ed/
2. https://github.com/tldr-pages/tldr/pull/944
3. https://github.com/tldr-pages/tldr/blob/master/pages/common/...
http://lists.gnu.org/archive/html/bug-ed/2017-01/msg00002.ht...
Sincerely, that other guy on your multi-user OS.
Ditto `:wq`. If you're in vim, and you don't know how to exit, you probably don't want the random keypresses you made while trying to figure out how to exit to be written to the file. Another case where an alternate version might be better: [ESC]:q! nano <file>
[1] https://www.youtube.com/watch?v=zdcPZc21agk
From my experience, people at least from Korea are very likely to develop on windows, even when targeting linux or even embedded linux.
You can tell from the msdos line endings and comments in Korean that are in a weird multi byte encoding that I could not make vim display correctly. I think they use some sort of sftp synchronization tool like WinSCP when you edit a file remotely.
I read that Windows is really deeply rooted in their IT culture, so much so that banking sites are required to use a special encryption scheme implemented in ActiveX. I can see why that would discourage people to use a different OS for their daily needs, let alone convince corporate IT to support dual boot.
ZQ - Quit without saving
ZZ - Quit with saving
In my experience almost all of my colleagues over the past 5 years only new of :q, not ZQ.