Pet peeve: Vim should be spelled "Vim," not "VIM."(1) Consistency in case would also make it easier to read in my opinion, Vim/VIM seem to be used interchangeably throughout the article.(2) Other than that, this is a good crash course. =)
I don't think executable size makes a huge difference for this type of application. All static sections of a given binary is shared among all users; code, globals, and shared libraries. Even the non-static parts are copied on write.
Thats exactly what I like about Vim..
Small footprint is really great on an multi user environment or when editing or viewing large files like logfiles.
I was used to editing files over ssh with Vi, but after they improved;) I was hooked on Vim forever. Vim really is an absolute a must-have skill in your toolbox.
There's a myriad of vim-tutorials around the Net, but I find that people usually tend to forget that vim has a built-in tutorial. Of all the ones I've found, this is really one of the best. Most importantly, it's interactive, and I'm a 'learning-by-doing' person. Just type `vimtutor` at the command prompt (also `gvimtutor`.)
Not to diminish on the author's efforts. The tutorial he wrote taught me about vim's capabilities in directory mode — I would usually just quit every time I accidentally ended up in it.
Another important vim tip for me that wasn't in there and might be one for the author himself: you can use ctrl-C or ctrl-[ instead of ESC to exit insert mode. This, combined with re-mapping capslock to control, is a big, big win.
Ctrl-c and ctrl-[ are not the same. There are times when latter completes the insert session (same as esc) while the former aborts it, e.g. visual block insertion with (ctrl-v jjjj I)
Also, the happy haacking keyboard already puts control in its proper place and puts esc where ~ normally is, which is close enough that you don't really need to remap it. Best vim keyboard ever.
It's more helpful to think of ctrl-[ as an analog to ESC (this also works in Emacs, irssi, etc as well IIRC). Ctrl-c just happens to work for exiting Insert mode because ctrl-c is the 'abort' command, and technically Insert mode is an operation.
Insert mode is not Vim's 'normal' mode. When you enter Insert Mode, you are basically saying, "I'm stepping out of normal mode for a bit to enter some text here." In this sense, hitting ctrl-c is telling Vim that you're aborting your insert operation. (Though I could just be talking out of my ass, and it was just bound that way as a convenience)
but be sure to choose something you won't mind typing in regular non-vim contexts as well, as you'll eventually pick up a habit of hitting your <esc> equivalent pretty much whenever you stop to think. <ctrl-w> would be a horrible choice :)
It's also common to remap ii to exit insert mode, that way "i" puts you in, "ii" takes you out.
Personally, I remapped caps lock to esc, because I don't like the way the editor lags when typing an "i" after "ii" has been remapped, but Caps-->Ctrl has the additional benefit of making other Ctrl-Foo sequences easy.
> Personally, I remapped caps lock to esc, because I don't like the
> way the editor lags when typing an "i" after "ii"
That's the problem with mapping non-Ctrl/Alt sequences in Insert mode. Even thing like bindings that automatically insert a closing } (with auto-indent) when you type the opening { are really annoying because they are commonly bound to the sequence "{<Enter>". So when you type { without <Enter> there is a delay while it waits to see if you're going to hit <Enter>.
Incidentally I also remap jh to write & exit insert mode (inoremap jh <ESC>:w<cr>). This turns out to be super helpful for web development, which often requires that you hop over to a browser after modifying code.
This gets annoying sometimes if you're working in an unnamed file. If you haven't saved yet, or don't intend to (just a scratch buffer or something) it throws an error every time you switch contexts.
I personally just remap capslock to ESC directly. I'm in vim a large majority of the time that I'm working, so it's a very big jump in productivity for me.
Some vim users also remap their caps lock to Esc (modify ~/.Xmodmap on linux, also doable on Windows and Mac), whereas Emacs users will probably remap their caps lock to Ctrl.
Vim is ancient yet its idea can be quite advanced: we have 10 fingers so why not use as many of them as possible?
It's like a puppet master wiring her fingers to fully express herself through the puppet. In the case of programming, Vim is the wire and the puppet is the code.
Or Pentadactyl - an improved fork of vimperator by it's most active developers. Probably the only thing keeping me from using Chrome as my main browser
http://dactyl.sourceforge.net/pentadactyl/
I might've found this out through HN, in which case this'll be redundant. Still, I'll risk it: http://vimcasts.org/ is a good resource.
This fellow puts up bite-sized, five minute screencasts of various Vim-related features. Some of the 'casts are more advanced, and some of them are pretty basic.
You can make use of the foldcolumn. The fold column is an optionally visible column that can be put between line numbers and text. It is generally used to show markers to indicate level of folding, if any. If you want to use it to create separation between line numbers and text, but don't want to see the folding markers, just set the foreground color of the fold column to be same as the background color. So something like this:
Very sorry, my mistake. I thought I had checked and confirm that it did appear to the right and I must have looked too quickly. No, I don't think there is a way to swap those columns. (At least not through Vim 7.2, Vim 7.3 introduced relative line numbering and maybe it has a teak in addition to that -- but I doubt it.) It's not too hard to adjust line indenting so it defaults to minimum that is greater than 1, say 2 or 3, but that would be sort of an ugly hack, inserting blank spaces into your document for mere purpose of viewing more space between line column and text.
I do not know if it's possible to do what you want. I find that a slight variation in background color (:highlight LineNr) helps in distinguishing the numbers from the content.
Also, :x is the short version of :wq(also available in vi). And some people put their rc files up on github, here is my vimrc file: http://github.com/wei23/dotfiles/blob/master/.vimrc I cherry-picked a lot of useful features from different vimrc files on github and dotfiles.org
TextMate is getting older and older. I would like to try something else, but I haven't yet found another editor with a sane file/folder sidebar, which is a must for me. Any tips? The sidebars I've seen for emacs and vim either look lika crap or use too big a font for them to be practical.
If you program, please try SnipMate.vim.
There are plenty more very helpful plugins, but this one is great and is programmable.
And don't forget pathogen.vim.
Yankring, command-T or fuzzyfinder, surround, repeat, align, ack and fugitive are others i recommend.
Its amazing that after having read probably hundreds of Vim tutorials / guides every user is able to learn something completely new from every one of them.
It sure scales.
This one brought ^T and ^D for indenting in insert mode to me, and starting with -o/O as argument for opening multiple files in splits.
also, ciw which I use far more often than cw (don't need to be on beginning of word to change the whole thing). I like how all the ci commands always elicit a "whoa, what did you just do?" from people watching me edit.
It's this kind of magic that attracted me to Vim in the first place. I watched a professor doing that stuff in front of class and my jaw dropped. The circle was complete when a coworker watching me modify some code had a similar reaction. (Sadly I did not convert him.)
Vim is a great editor, it just lacks a decent implementation; GNU Emacs is a great OS, it just lacks a great editor. GNU Emacs + Viper + Vimpulse is what you should learn and use for maximum effectiveness.
I'm in the Emacs camp. However, vi has a certain minimalistic efficiency to it for development. Let me add that a pro might want to quit with :x instead of :wq.
It's probably best to learn a bit of both, but specialize in one. Especially since common tools like `less` use vim bindings. Examples:
* `less +23 file.txt` opens the file in less at line 23
* Searching in less works just like vim:
/ -- starts a forward search
? -- starts a backward search
n -- cycle through matches forward
N -- cycle through matches backwards
* Some movement keys are shared:
gg -- go to the top of the file
G -- to go the bottom of the file
ctags + fuzzyfinder plugin gives you TextMate like symbol lookup. (there's another textmate-like plugin whose name escapes me that's a bit more faithful to the TextMate lookup.)
Emacs is self-documenting, so you only need two things to use Emacs like a pro -- Emacs, and your brain.
The first thing a new Emacs user should do is to peruse the Emacs manual. You won't remember every detail, of course, but you should at least have a basic idea of what sorts of operations are available.
Then, start editing text. When you do something that seems tedious, you're doing it wrong. Try to remember back to the section of the manual that has something to do with what you were doing. Then read that section. Now try to redo the operation, but "the Emacs way" instead of the tedious way you invented yourself.
1 See spelling in use at http://www.vim.org/about.php
2 "Vim has a small footprint in RAM and on the CPU. A given system can support a great many VIM users at once."