Vim is an editor that requires a significant early investment to learn how to use with any effectiveness. It then takes a significant early investment to get comfortable using it. After that, you could spend the rest of your life learning to use it, learning something new about it every single day, and still have more to learn after forty years. The investment in the learning curve is definitely worth it in my opinion, however, as the productivity gains I have achieved using Vim, and the comfortable intuitiveness of it, by far eclipse any initial investment in learning it.
Note that this is all predicated upon the assumption that you touch-type using a QWERTY keyboard layout. If you don’t, you’re better off using something like SciTE instead. An editor doesn’t get as intuitive and productivity-enhancing as Vim is without doing so for a strict subset of typists, and the primary assumption on which Vim relies is that you’re a QWERTY keyboard touch-typist. I hear it works reasonably well for Dvorak keyboards, too, but there are one or two things that end up slightly “off” unless you change some of the defaults for Vim commands.
Vim is open source (but, alas, not copyfree) software that is in the software management archives of every major open source Unix-like OS in existence, including BSD Unix systems and Linux distributions. As such, installing is trivial on such systems. Check the software installation process particular to your open source Unix-like OS of choice for details.
I recommend getting the console-based Vim and using that at first, if that is reasonably possible. If you are using MS Windows and aren’t the type to use Cygwin or some other Unix emulation environment, though, you should probably use gVim instead. GVim is a version of Vim that comes with a GUI interface, complete with clicky buttons, and is pretty much a necessity if you want to use Vim in a standard MS Windows environment because of the severely crippled support for console-based applications on that OS. Other than under such circumstances, the only time I’d recommend gVim is when you try out the console-based interface first and discover that you just can’t handle a more keyboard-driven text editor at first and need a more gentle introduction to modal, keyboard driven editors.
Before giving up on the console-based interface, though, try it out for a few days (or, if you don’t do much text editing in an average day, maybe longer).
Anyway . . . if you’re on an OS that, like MS Windows, doesn’t have a modern software management system, or you want to install Vim outside of your software management system for some reason, you can download Vim from the Web. Many open source Unix-like OSes come with Vim already installed, though, so you may not even have to install it. Be aware that some of them (such as Ubuntu) have a “slim” version of Vim installed by default instead of the standard Vim editor, however. This lighter weight version lacks some functionality, and if you don’t have a compelling reason to use the smaller version, you should probably just install the full-size version. Even the standard, full-size version is smaller than two megabytes, last I checked, so you aren’t likely to consume an undesirable quantity of storage space on your hard drive.
With less productive, more GUI-oriented text editors (how do you like the way I slipped that bias in there?), you’re probably used to opening a text editor, getting a blank, untitled file, and filling it with text before deciding on a name and saving it. You can do that with Vim, too, but I recommend you adopt a different approach when using it. Instead, specify the name of the file when you first open it.
The console-based Vim is started with a command entered at the shell prompt. You’ll probably do this within a terminal emulator such as KTerm, GNOME Terminal, ETerm, XTerm, the MacOS X Terminal, or rxvt. Entering the command
vim is enough to open the editor, but to open it by specifying a file name (such as an existing file you want to edit or a new file you create at that moment), you would enter something like:
Part of the reason I recommend specifying the name in advance is that Vim caches your file to the hard drive every now and then by default in case of a crash (as in the case of someone tripping over the power cord of your computer and causing it to be unplugged while you’re in the middle of typing). The next time you open the file, if you specify the same file name, it will offer options for recovering the file from that cached version of the file. Otherwise — well, I’m not really sure what it does, otherwise, because I’ve never had to find out. Maybe it doesn’t create a cached version until after the first time you save it. Maybe it uses some cryptic name based on the time and date, or a default name. I just think it’s a good idea to name your file when you open it. If you disagree, do things differently.
Using Modal Editing
When learning Vim, the first thing you need to know is that it uses modes for different parts of its operation, and if you start trying to enter text while you’re in the Command mode you can do all kinds of weird damage to a text document. Luckily, you can probably undo the damage very easily, as long as you don’t accidentally save and exit the program while you’re busily doing damage.
The program starts up in Command mode. In Command mode, you can use single-character keyboard shortcuts and typed commands that start with a colon to achieve quite a lot of very efficient editing very quickly with very few keystrokes (once you learn how, and get familiar with it). Actually, Command mode is what it’s called in old-school vi; Vim is an extended, “improved” version of vi. Vim calls it “Normal” mode, which I find silly, so I keep calling it Command mode.
To start actually entering text normally, you need to enter Insert mode. Do that from Command mode just by pressing the
<I> key. To exit Insert mode, going back to Command mode, press the
To undo changes, pres the
<U> key while in Command mode. The entire last time you were in Insert mode, complete with any changes that were made in Insert mode, is considered a single change for purposes of undo/redo. To redo something you just undid, type
:redo and hit enter — the
: tells Vim you’re going to type a command.
Saving and exiting must be done in Command mode. To exit without saving, use the
q! command (i.e., type
:q!). To save without exiting, use the
w command. To save and exit all at once, you can use the
x command. To specify a filename when saving it, in a sort of “Save As” situation, you can do so with a command like:
Finally, it might help to understand the philosophy of modal editing. For that, Why, oh WHY, do those #?@! nutheads use vi? is what I recommend reading.
You really just have to use the hell out of it to get comfortable. It will probably prove somewhat difficult at first, but as I already said, I think the initial learning curve is well worth it for the long-term productivity gains. If that’s not true for you, c’est la vie.
A few resources for learning more:
If you have Vim installed on your computer, you should be able to start a tutorial for it by entering
vimtutorin a terminal emulator window.
There’s a built-in help system in Vim that you can use to search Vim documentation for how to perform specific tasks. It doesn’t always provide the most intuitive approach to finding what you need, but you get to it by typing something like
:h searchin Command mode, where “search” is a search term. In fact, if you literally enter
:h searchin Command mode, you’ll get help information on how to search a document for text that matches a particular regular expression.
The same site that offers the explanation of the philosophy and benefits of modal editing, linked above, also offers some vi/Vim tips.
The Vim Tips Wiki might be of some use to you.
So might Mastering the VI editor.
Be sure to check out the Vi Lovers Home Page.
You might want to bookmark a Vi Cheat Sheet. This is just one of many on the Web.
An excellent book for learning about how to make your way around in a Unix-like environment without the GUI — good for both experts and novices — is A Practical Guide to Linux Commands, Editors, and Shell Programming. It has a decent section on vi/Vim in it, too.
More resources can be found on the Vim subreddit.
. . . and Beyond
Hopefully, you find that helpful. I’ll probably provide some Vim usage tips that I’ve found particularly helpful and somewhat unobvious in the near future.
Once you really learn how to use vi/Vim, you can learn to throw the vi gang sign, and be a vi gangsta.