I've been looking forward to the day I have time to allocate to learn vim. This post was the first one I've seen that would allow me to jump in it quicker.
I found the best way is to force yourself by not using a GUI. I bought my first VPS a couple of years ago and started editing code on there (faster to compile than my laptop too). All dev work happens through SSH and screen to the box under my desk now, and it feels so much more productive.
Solid advice. I like the idea of minimizing plugins and mastering the fundamentals, because this is true strength of vim.
If I was pinning my productivity on customizations then emacs would be the clear choice.
If I wanted the perfect coding environment for language X, there's a good chance it would be an IDE.
But with vim, I can open any text file on any system and edit the hell out of it amazingly efficiently. It's extensibility is a nice bonus (very nice in some cases! eg: https://github.com/tpope/vim-fugitive), but at its core it's about raw text manipulation.
Nicely done. A new or returning vimmer will profit from following his advice.
His best recommendation is at the top: don't configure a lot of settings and plugins at first. Start with a minimal setup, and slowly work up from there when needed. In particular, don't copy someone's huge .vimrc.
In fact, that's good advice for any tool or technology: start minimal, and only add what you need, when you know you need it.
To his minimal initial configuration, I would suggest one addition: set a colorscheme that looks good to you in the terminal/gui environment you normally use, and choose from the default schemes rather than downloading a pack of them. I like elflord (it doesn't use a lot of red, which is hard to read on a black background), YMwillcertainlyV.
To see which scheme you're currently using, open an existing file in your favorite language and then:
:colorscheme
To cycle through the available schemes:
:colorscheme<space><tab>
Each tab will show you the next scheme's name; hit enter to try one.
Out of curiosity, why would you suggest choosing from the default schemes? I picked my scheme from a downloaded bundle and then installed a plugin to make it work on a 256 colour terminal.
Because that minimizes futzing around. Certainly if the colorscheme makes a difference to you, and you can't find one that satisfies you in the defaults, then you should try to find a better one, but I think you should try the defaults first. Trying to use what's already there is in keeping with minimizing the urge to "install all the things!"
Another nice tool to learn (or relearn) vim is vimtutor. I wish I had known about vimtutor when I first started learning vim, as opposed to launching vim and panicking when I accidentally wrote over some files I was editing.
Also, openvim.com has an excellent online tutorial that's convenient.
I remember reading the web page I linked to below some time late last year, and remembered thinking at the time I wished someone told me this when I first started learning vim some 18 years ago.
To those who would say “that’s obvious; of course you learn
vim incrementally”, I would simply say that having spoken to
a number of vim users in the past, I never got that advice.
Instead, I got a lot of advice about turning off my arrow
keys, disallowing the use of the mouse, and learning the
(MORE EFFICIENT!!!) vim ways to do everything, all at once.
People just couldn’t stomach the idea of me continuing to
use an outmoded practice (like apple-f) when vim had much
better tools available just a (huge volume of) memorization
away."
The reason so many experienced people suggest learning the basics of Vim (or, in my case, Emacs) in one go is because it works quickly and efficiently--certainly more quickly and more efficiently than an incremental approach. Additionally, just giving up on arrow keys and the like does not necessarily entail a "huge volume" of memorization.
I am an inherently lazy person; I cannot just sit down and memorize stuff (one of the reasons I'm in CS). Yet I definitely support giving up the mouse and arrow keys immediately.
When I originally picked up Emacs, I went through the tutorial and promptly forgot exactly which keys did what. However, I decided to follow the tutorial's advice and learn how to navigate properly. To do this, all I did was not use the mouse or arrow keys for editing some text. For the first couple of days, I had to keep looking the keys up each time I did anything; later--relatively abruptly--I started using them without realizing. There is no way I would have learned nearly as much as quickly if I had not got through a couple days of not knowing what I was doing.
Once the standard moving commands became second nature, I started using some of the more specialized ones (like moving around by line or paragraph or expression). Without having given up on the arrow keys and mouse, I would probably never have learned the more advanced movements which are now exceptionally useful.
Basically, to follow your suggestion would be to avoid a couple days of bumbling around in favor of being less effective for a very long time. On the other hand, with my approach, I did spend a couple days being incompetent but then the bindings became natural. Ultimately, to me, being lazy involves not just minimizing work immediately, but increasing efficiency in the long run as well.
As a contrast, I know many classmates who have tried to learn Emacs your way. Most of them can use it, but not much more efficiently than notepad; I regularly see them spending minutes doing menial tasks that would have taken seconds had they known Emacs better. In the context of a 90 minute lab, that is not trivial at all; even in the context of working full time, the amount of time they can save should not be ignored.
Ultimately, all it takes to learn Emacs (and, I imagine, the same can be said of Vim) is a little bit of patience and willingness to embrace change. By jumping into the deep end immediately, you can learn really quickly, and reap the benefits almost immediately.
The thing about vi vs emacs is that at the very beginning the learning curve for vi is already very steep. Simple things like keyboard navigation and even editing are non-trivial tasks.
This puts off a lot of people, especially if they're working full time as a couple of days fumbling with a text editor equates to real dollars lost in productivity. (In my experience though, it'll take at least a few weeks to be even mildly proficient).
If you're a student (I was 13 when I first picked up vi) this is no problem, as I had infinite time on my hands, but when you're working full time, the amount of time you have to experiment drastically reduces.
I don't think the initial difficulty of Vi is that much greater than that of Emacs. The real difficulty is in the fact that everything is completely different from what you are used to; perhaps this is more true in Vi, but the difference between Emacs and Vi in this regard pales in comparison to the difference between using a mouse and arrow keys and either of the text editors.
Also, while my approach will certainly cause a small amount of difficulty at the very beginning, I think you will actually win out in the long run. That is, let's say you normally code at 1 productivity unit (whatever that may be). My way, you may spend a some time at 0.1, then a bit of time at 0.5, but, in a couple weeks at most, you will start working at 1.5 or 2 or more. On the other hand, while still using arrow keys, you may first be at 0.8 for a bit, then back at 1 then maybe at 1.2. But you will not see any drastic improvement for a while, and so will actually be less efficient in the long run.
I use VIM and sometimes use the arrow keys. These come in really handy when you have a lot of small edits to make that can't be readily automated (not really that frequent).
However the huge shift in mentality has to go from the idea that you are working with a "text editor" (which VIM and EMACS are not IMHO) and a text processor which I would argue these are.
When you start thinking about processing rather than editing text, the productivity goes way up. There is nothing like these tools in the text editor world for editing large, complex codebases. IDE's can't compare.
Finally a vim user that admits to using the arrow keys. I have them disabled in command mode (just to annoy my co-workers) but regularly use them in insert mode when it's to much of a hassle to hit the escape key.
I didn't see the problem with arrow keys either. They really do break flow though. I only recently discovered how much better the home key navigation is over arrow keys. Every time you move you hands away from the home row you incur a small mental task of making sure that you move your hand over there and that the hand is correctly positioned. It sounds trivial but it really adds up to one less thing to think about.
Couple this with inoremap jj <Esc> and it eliminates the majority of large movements away from the home row.
Say you are in the middle of a word that you want to change compare:
Arrow key right until at end of word, i, backspace until at start of word, type new word, Esc three excursions from home row.
Ciw, type new word, jj. No excursions from home row and less of a mental load.
I guess all of those actual vim users had a reason to encourage you to take the "extreme route" instead of the incremental one. Maybe they have never seen anyone actually succeed in getting fluent in vim by incremental learning?
I know I have yet to witness such.
But I'm glad to learn from your link that it's possible. I'll show it to aspiring vim users as an alternative take to learning vim.
I've used Pathogen previously and I have to say I much prefer Vundle. It's the only plugin I have to manage in my .vim directory. All the plugins I use are listed right in my vimrc, and running :BundleInstall does a git pull from each plugin's repository which gives me the latest updates. I use terminal-based vim for all of my coding and text editing all day, and my vimrc is only 91 sloc.
I think the advice to stay away from highly customized environments and hacks is really the way to go. A huge strength of vim is that you're going to find it on any server you end up using.
Disclosure: I didn't disable my arrow keys when I started with vim, but after a few months I did end up doing it to really brand the h/j/k/l movements in my mind.
One problem I had with Pathogen using git submodules (and presumably Vundle as well) was the inability to tweak my plugins. I wanted the ability to be able to modify several of the plugins I had installed and I couldn't figure out a nice way of doing this. In the end I opted for git subtrees but this also seems like an overcomplicated solution.
For tweaking plugins, you should use .vim/after/plugin/NAME.vim files. Otherwise, clone the repository, make your changes, and initiate a pull request.
I just want to thank the hacker news community. Vim is the kind of tool that requires a lot of persistence and hand holding to learn. I'm slowly learning and understand how I can use it to fundamentally change the way I do work on the computer. So thanks for highlighting and writing these helpful posts. they make a difference.
I use and like Vim, but I feel like the articles that make it to HN all say the same thing ("I had a conversion experience," followed by some configuration details, followed by basic keystrokes, etc).
Why does everyone feel the need to re-tell the same story?
To get more people to use Vim. It's also annoying when IDE people assume that Vim and Emacs people are just old-fashioned and using inferior tools; explaining why and how you use Vim is a great way to dispel these misconceptions.
I've been using Vim more or less exclusively for the last year or so, and there is only one feature of Aptana Studio that I miss, and have not been able to find in any Vim plugins. In the directory/project tree in Aptana, files had different styles based on their git status. I think I just need to take a weekend and learn enough vim programming to make it happen as a Nerd Tree plugin.
OT: This is such a beautifully designed blog. One of the few that I don't immediately pass through Readability or something similar in order to, you know, read it.
This is one of my favorites; until I learnt about b# (:b#) to 'toggle' to the last open buffer. Quickly remapped this to <leader>, (being ,,). Et voila: lightning-uber-fast-buffer-toggling.
If only I had read this when I first started using Vim!
I've been using Vim for a while, and this is one of the best-organized overviews of Vim I've seen, partly because he doesn't try to enumerate every single key combination (which is the wrong way to learn Vim - the right way is to synthesize the way that the individual operations are logically combined, though that admittedly takes some time). The best two pieces of advice he gives are (1) not to put anything in .vimrc without knowing exactly what it does, and (2) don't use too many plugins.
At this point, I actually don't think I really use any plugins regularly. I have nothing against Vim plugins in general. It might be a bit faster to install a choice few, sure, and someday I might try and figure out which ones work best for me. But for the time being, I'd much rather know how to navigate my file or project with just the standard set of operations and minimal configuration. That way, I can launch Vim on any machine and start using it, without needing to waste time setting it up just so I can use it properly.
(Disclaimer: I have mapped Caps Lock to Esc, which is indeed a major problem if I use another person's computer. I've gotten used to seeing "E492: Not an editor command: W" practically every time I type on a friend's laptop. But it saves me so much time when working on my own machine that it's worth it!)
In short: stick with Vim long enough, and you'll find that you don't really need many plugins or much configuration for it to be incredibly useful. They help, but not as much as you might think, especially once Vim's standard keybindings become part of your keyboard reflexes.
I used jj for a while as well, but once I found out that ctrl-C did the same thing out of the box, that became my "esc" key> (it's also important to remap caps lock to control, on the mac its easy: System Preferences->Keyboard->Keyboard->Modifier Keys)
What about changing hjkl movements to jkl;?
I didn't try it yet... But hjkl bothers me.
My index belongs on j, for homerow touch typing, not h.
Wouldn't it be an improvement? Not having to move the hand for movements.
I must be missing something because everyone stays with hjkl.
The keys I use most are up/down. I tend to move between lines more often than I move between characters. This is true in any editor, but especially in vim, since I almost never move between individual characters, but rather use [w]ord movement commands, or [f] commands, etc.
That's why it makes sense that my strongest fingers are on the up/down motions, whereas to move to the left, a movement I never make, is off to the side.
Also, I wouldn't remap it for practical reasons - hjkl is a standard implemented in many places.
I'm much faster in vim since I gave up (for the most part) on hjkl (arrow keys are banned for obvious badness). / ? # * combined with f and t are so much faster. The only time I use j/k is 10j/10k for looking through files.
I did this for about two months before switching back to hjkl. There are two reasons why I switched back:
* I like using "Ctrl+Direction" to move around splits, and mapping Ctrl+; on a Mac doesn't work without some Keyremap4Macbook trickery. It's a pain to get working.
* Tons of other stuff uses Vim bindings, and you can't usually remap keys in most other programs.
Why people always emphasis h/j/k/l when we already have arrow keys? Do you really waste a lot of time moving your fingers between them? Also, arrow keys work in insert mode.
This is a perfect place to post a Vim tip that I think helped me the most in starting out.
Disable arrow keys.
It's extremely painful for the first 5 days but I promise that's all it takes to get use to it. And it makes huge difference in your productivity. All that time does add up.
The reason you want arrow keys disabled in insert mode is that arrow keys breaks the modal paradigm. Again, I promise that once you get comfortable, it becomes more efficient to go into editing mode and make the change rather than navigate via the arrow keys in insert mode.
I learned vim's movement keys by playing nethack on a laptop without a number pad. This is a very fun way to learn hjkl. It also punishes you quickly if you make a mistake.
It's absolutely worth it. After many years, I don't even think about it any more. I just navigate using the home row. In fact, when I look at the keys, I can't tell you which ones go in which direction. I have to think about what my fingers do when I want to go in that direction. After time, it becomes sub-conscious, like playing a videogame.
* If you want to stop seeing vim as a series of unforeseen tricks, take the time to learn the 300-400 keybindings you find useful. I'd recommend a free flashcard program like anki which also has a vim flashcard set, https://github.com/amikula/vim_flashcards
* One helpful pattern I've noticed in memorizing keybindings: uppercase, left characters i.e. P, ( map to above and reverse; lowercase and reverse characters i.e. p, ) map to below and forward
>I learned this the hard way: you shouldn’t start with a huge .vimrc file that you copied from someone else nor should you install every single plugin that seems useful at that moment.
This is probably the most valuable piece of advice in the article. I have over a number of years looked at the tangled mess that my .vimrc had become, but always put off cleaning it up because I really didn't understand what some of the things did.
I thought to myself: Yes some of the keys act a little funny (sophacles/vim-bundle-python had awful, conflicting use of [c when I used Vimdiff on a python file), and yes I get warnings about some things, but hey, I must have put all this stuff in the config file for some reason.
Well, tonight I finally pitched my whole .vimrc (https://gist.github.com/1464673) and I am much happier as a result. I realized that I didn't need all that stuff to be productive, and I never probably used any of it anyway.
critical: Map Caps Lock to control and use control-[ instead of escape.
It's very easy to do on most OS's today and not having to move your hand from the home row when you switch into command mode is as big as proper use of jump commands imo.
I also agree to avoid all massive .vimrc files. If you don't understand it, don't use it. Simple.
Oh, sorry, I should clarify -- I want to remap it to Esc.
Or, to be more precise, I want Caps Lock to somehow switch modes in vim in a terminal app. If that means configuring something on both sides, the OS and vim, I'm cool with that.
I've tried a number of things but nothing seems to work right.
I had been using Vim for years, and this is fundamentally one of the most useful settings I came across. I think it's only available it the latest rel.
Funny side note, I was out on the town one night and saw a bunch of guys and girls hacking on their laptops... in a club. I noticed one guy using Vim, came up behind him and told him he has a good taste in editors. It turns out he's Jay Freeman (saurik). I showed him relativenumber and he was stoked. EOS.
I ran across some variation on this toggle somewhere. Very handy.
" toggle line numbers from absolute to relative with f2.
map <silent> <F2> :if &number <Bar>
\set relativenumber <Bar>
\else <Bar>
\set number <Bar>
\endif<cr>
Having unrelatedly just started using CommandT today, let me say how amazing it is.
I've been using vim as a supreme novice for a few years, and have only really tried to get to know it better in the past six months after switching to OS X and getting to use MacVim.
And already in one night CommandT has blown me away with how timesaving it is, and how much time I've wasted in the past not using it.
Not only is CommantT amazing, but I haven't seen something that good anywhere else. Seem that Peepcode has a similar things (but plugged in the system...), and that it comes from Textmate. But here the ability to change the working directory with some fast :cd change everything !
Good advice, although I personally disagree with him on the Janus front.
Janus is what got me to switch full time to Vim a few months ago, after having used Vim off and on for over a decade, mainly on the command line or for edits that were to difficult or repetitive to get done in more "friendly" editors/IDEs like TextMate and Visual Studio.
Janus provided just enough familiarity and convenience to make a full-time swap something I could stick with. After a couple of months of this I did basically dump Janus and start managing plugins myself with Pathogen (adding new ones and removing some of the default Janus ones), and customising my config (which is still based on the old Janus config, but extensively modified)
Agreed he seems to just dismiss Janus randomly, instead prefering to tell people to what...assemble the plugins by hand and just copy his vimrc config? not ideal.
that's almost but not quite entirely unlike what he's suggesting, which is to start with a minimal .vimrc, understand every line in it, and gradually add tweaks and plugins as you see the need for them and understand how to set them up.
"Don’t use the NERD tree plugin. It is clumsy, will hurt your workflow with split windows, and it’s not particulary pretty either. You never needed a file browser pane in the first place."
"It is clumsy"
We're talking about VIM, with dozens of keystrokes to invoke everything but emacs already. The whole thing is a bit clumsy! I use it every day and have for a decade but it's still clumsy.
"will hurt your workflow with split windows"
The author then goes on to state
"You can split the current buffer horizontally or vertically. This is useful, for instance, to view simultaneously the top and the bottom part of the same file. But it’s even more useful to view different files in splits; for instance tests and implementation."
HUH?
" and it (nerdtree) ’s not particulary pretty either"
And the rest of VIM is?
Nerdtree is great, especially when I'm using it on remote systems. A vim session open with nerdtree and some tabs inside of a screen session, and life is good.
I though it interesting that after hating on NERDTree, he went on to suggest a plugin that requires Ruby and VIM compiled with Ruby support, which isn't likely to exist on most.
I'm not a VIM purist. I use the arrow keys, and I use the mouse a lot. I find NERDTree to be tremendously easy to use and helpful when on a local system.
On remote systems, though, I generally just edit 1 file at a time and don't need NERDTree. For multiple files, :e works just fine in those situations.
You've misinterpreted the "hurt your workflow with split windows" bit. You understood it as if NERD Tree's split window is what hurts your workflow. I was saying that my existing split window workflow was hurt by presence of the NERD Tree.
I toggle nerdtree on and off often, so it's there when I need it, and gone when I don't, so I don't notice it getting in the way of my split windows all that much.
As another recent convert to Vim, I always get something out of reading these articles. However my primary advice would be to just accept that the process of learning Vim is inherently painful, but the suffering is mostly over after a couple of months. Expect your productivity to drop during this period though.
It's also true that Vim 'suffers' from the open source infinite configurability issue. That is, it is so configurable that you'll spend a significant amount of time configuring it to your tastes rather than getting work done. This tails off over time of course. Slightly more awkward is that it's also easy to shoot yourself in the foot. For example my current config has an issue where on rare occasions undo sporadically fails, and ends up undoing line insertions by deleting the wrong line! Ouch. I still have several such issues, but not enough to deter me as yet.
Another thing to consider is that Vim is not equally suited to all developers. If you're editing a bunch of different file types with mostly consistent libraries I think it's a great fit, which describes a lot of web developers. In that case you just want world class text editing. If you're editing mostly C++ with a bunch of different APIs and libraries, the loss of decent codesense/autocomplete forces you into lots of very slow doxygen searching in a browser. I've tried various solutions to this such as clang complete and eclim, but ultimately Vim is not an IDE and there's no way to make it act as one.
Overall I'm happy to have made the switch though, since the editing itself is so very smooth. It's great to have the same environment in a remote shell as well.
116 comments
[ 2.6 ms ] story [ 179 ms ] threadIf I was pinning my productivity on customizations then emacs would be the clear choice.
If I wanted the perfect coding environment for language X, there's a good chance it would be an IDE.
But with vim, I can open any text file on any system and edit the hell out of it amazingly efficiently. It's extensibility is a nice bonus (very nice in some cases! eg: https://github.com/tpope/vim-fugitive), but at its core it's about raw text manipulation.
His best recommendation is at the top: don't configure a lot of settings and plugins at first. Start with a minimal setup, and slowly work up from there when needed. In particular, don't copy someone's huge .vimrc.
In fact, that's good advice for any tool or technology: start minimal, and only add what you need, when you know you need it.
To his minimal initial configuration, I would suggest one addition: set a colorscheme that looks good to you in the terminal/gui environment you normally use, and choose from the default schemes rather than downloading a pack of them. I like elflord (it doesn't use a lot of red, which is hard to read on a black background), YMwillcertainlyV.
To see which scheme you're currently using, open an existing file in your favorite language and then:
To cycle through the available schemes: Each tab will show you the next scheme's name; hit enter to try one.http://www.vim.org/scripts/script.php?script_id=1651
Also, openvim.com has an excellent online tutorial that's convenient.
I am an inherently lazy person; I cannot just sit down and memorize stuff (one of the reasons I'm in CS). Yet I definitely support giving up the mouse and arrow keys immediately.
When I originally picked up Emacs, I went through the tutorial and promptly forgot exactly which keys did what. However, I decided to follow the tutorial's advice and learn how to navigate properly. To do this, all I did was not use the mouse or arrow keys for editing some text. For the first couple of days, I had to keep looking the keys up each time I did anything; later--relatively abruptly--I started using them without realizing. There is no way I would have learned nearly as much as quickly if I had not got through a couple days of not knowing what I was doing.
Once the standard moving commands became second nature, I started using some of the more specialized ones (like moving around by line or paragraph or expression). Without having given up on the arrow keys and mouse, I would probably never have learned the more advanced movements which are now exceptionally useful.
Basically, to follow your suggestion would be to avoid a couple days of bumbling around in favor of being less effective for a very long time. On the other hand, with my approach, I did spend a couple days being incompetent but then the bindings became natural. Ultimately, to me, being lazy involves not just minimizing work immediately, but increasing efficiency in the long run as well.
As a contrast, I know many classmates who have tried to learn Emacs your way. Most of them can use it, but not much more efficiently than notepad; I regularly see them spending minutes doing menial tasks that would have taken seconds had they known Emacs better. In the context of a 90 minute lab, that is not trivial at all; even in the context of working full time, the amount of time they can save should not be ignored.
Ultimately, all it takes to learn Emacs (and, I imagine, the same can be said of Vim) is a little bit of patience and willingness to embrace change. By jumping into the deep end immediately, you can learn really quickly, and reap the benefits almost immediately.
This puts off a lot of people, especially if they're working full time as a couple of days fumbling with a text editor equates to real dollars lost in productivity. (In my experience though, it'll take at least a few weeks to be even mildly proficient).
If you're a student (I was 13 when I first picked up vi) this is no problem, as I had infinite time on my hands, but when you're working full time, the amount of time you have to experiment drastically reduces.
Also, while my approach will certainly cause a small amount of difficulty at the very beginning, I think you will actually win out in the long run. That is, let's say you normally code at 1 productivity unit (whatever that may be). My way, you may spend a some time at 0.1, then a bit of time at 0.5, but, in a couple weeks at most, you will start working at 1.5 or 2 or more. On the other hand, while still using arrow keys, you may first be at 0.8 for a bit, then back at 1 then maybe at 1.2. But you will not see any drastic improvement for a while, and so will actually be less efficient in the long run.
However the huge shift in mentality has to go from the idea that you are working with a "text editor" (which VIM and EMACS are not IMHO) and a text processor which I would argue these are.
When you start thinking about processing rather than editing text, the productivity goes way up. There is nothing like these tools in the text editor world for editing large, complex codebases. IDE's can't compare.
Time to remap that one too.
As someone said, when programming typing isn't my bottleneck, thinking is.
Full touch-typing speed is a must for court clerks -- not for programmers, and also not even for writers.
Couple this with inoremap jj <Esc> and it eliminates the majority of large movements away from the home row.
Say you are in the middle of a word that you want to change compare: Arrow key right until at end of word, i, backspace until at start of word, type new word, Esc three excursions from home row.
Ciw, type new word, jj. No excursions from home row and less of a mental load.
But I'm glad to learn from your link that it's possible. I'll show it to aspiring vim users as an alternative take to learning vim.
https://github.com/tomhsx/dotfiles/blob/master/vimrc
I think the advice to stay away from highly customized environments and hacks is really the way to go. A huge strength of vim is that you're going to find it on any server you end up using.
Disclosure: I didn't disable my arrow keys when I started with vim, but after a few months I did end up doing it to really brand the h/j/k/l movements in my mind.
The newer versions of Vundle are fantastic, and give you features like lists of your current plugins and searching of the plugins repository.
Why does everyone feel the need to re-tell the same story?
This story is pretty different from, say, Yehuda Katz's story about switching to Vim.
I find all the different takes interesting, and I think you can casually learn from the differences between them.
Check out Steve Losh's Learn Vimscript the Hard Way[1].
[1] http://learnvimscriptthehardway.stevelosh.com/
I learn something new with these posts every time! I've been wanting something like this for a while.
I've been using Vim for a while, and this is one of the best-organized overviews of Vim I've seen, partly because he doesn't try to enumerate every single key combination (which is the wrong way to learn Vim - the right way is to synthesize the way that the individual operations are logically combined, though that admittedly takes some time). The best two pieces of advice he gives are (1) not to put anything in .vimrc without knowing exactly what it does, and (2) don't use too many plugins.
At this point, I actually don't think I really use any plugins regularly. I have nothing against Vim plugins in general. It might be a bit faster to install a choice few, sure, and someday I might try and figure out which ones work best for me. But for the time being, I'd much rather know how to navigate my file or project with just the standard set of operations and minimal configuration. That way, I can launch Vim on any machine and start using it, without needing to waste time setting it up just so I can use it properly.
(Disclaimer: I have mapped Caps Lock to Esc, which is indeed a major problem if I use another person's computer. I've gotten used to seeing "E492: Not an editor command: W" practically every time I type on a friend's laptop. But it saves me so much time when working on my own machine that it's worth it!)
In short: stick with Vim long enough, and you'll find that you don't really need many plugins or much configuration for it to be incredibly useful. They help, but not as much as you might think, especially once Vim's standard keybindings become part of your keyboard reflexes.
Now it does.
That's why it makes sense that my strongest fingers are on the up/down motions, whereas to move to the left, a movement I never make, is off to the side.
Also, I wouldn't remap it for practical reasons - hjkl is a standard implemented in many places.
Hence, your question is somewhat misguided ;)
Unless you mean you specifically use search for every motion...?
* I like using "Ctrl+Direction" to move around splits, and mapping Ctrl+; on a Mac doesn't work without some Keyremap4Macbook trickery. It's a pain to get working.
* Tons of other stuff uses Vim bindings, and you can't usually remap keys in most other programs.
Disable arrow keys.
It's extremely painful for the first 5 days but I promise that's all it takes to get use to it. And it makes huge difference in your productivity. All that time does add up.
Add the following to your .vimrc
The reason you want arrow keys disabled in insert mode is that arrow keys breaks the modal paradigm. Again, I promise that once you get comfortable, it becomes more efficient to go into editing mode and make the change rather than navigate via the arrow keys in insert mode.http://alfmikula.blogspot.com/2010/11/using-spaced-repetitio...
Some additional tips:
* As your # of plugins grow it helps to isolate plugin-specific config to separate files. Example: https://github.com/cldwalker/vimfiles/tree/master/after/plug... .
* If you want to stop seeing vim as a series of unforeseen tricks, take the time to learn the 300-400 keybindings you find useful. I'd recommend a free flashcard program like anki which also has a vim flashcard set, https://github.com/amikula/vim_flashcards
* One helpful pattern I've noticed in memorizing keybindings: uppercase, left characters i.e. P, ( map to above and reverse; lowercase and reverse characters i.e. p, ) map to below and forward
* If you're looking for a more powerful to search your vim docs, check out my vimdb project, http://github.com/cldwalker/vimdb
Do you mean 30-40?
This is probably the most valuable piece of advice in the article. I have over a number of years looked at the tangled mess that my .vimrc had become, but always put off cleaning it up because I really didn't understand what some of the things did.
I thought to myself: Yes some of the keys act a little funny (sophacles/vim-bundle-python had awful, conflicting use of [c when I used Vimdiff on a python file), and yes I get warnings about some things, but hey, I must have put all this stuff in the config file for some reason.
Well, tonight I finally pitched my whole .vimrc (https://gist.github.com/1464673) and I am much happier as a result. I realized that I didn't need all that stuff to be productive, and I never probably used any of it anyway.
It's very easy to do on most OS's today and not having to move your hand from the home row when you switch into command mode is as big as proper use of jump commands imo.
I also agree to avoid all massive .vimrc files. If you don't understand it, don't use it. Simple.
Or, to be more precise, I want Caps Lock to somehow switch modes in vim in a terminal app. If that means configuring something on both sides, the OS and vim, I'm cool with that.
I've tried a number of things but nothing seems to work right.
I had been using Vim for years, and this is fundamentally one of the most useful settings I came across. I think it's only available it the latest rel.
Funny side note, I was out on the town one night and saw a bunch of guys and girls hacking on their laptops... in a club. I noticed one guy using Vim, came up behind him and told him he has a good taste in editors. It turns out he's Jay Freeman (saurik). I showed him relativenumber and he was stoked. EOS.
I've been using vim as a supreme novice for a few years, and have only really tried to get to know it better in the past six months after switching to OS X and getting to use MacVim.
And already in one night CommandT has blown me away with how timesaving it is, and how much time I've wasted in the past not using it.
Both have pros and cons; both are in the same everlasting-holy-war and once in a while either will start a new crusade.
Janus is what got me to switch full time to Vim a few months ago, after having used Vim off and on for over a decade, mainly on the command line or for edits that were to difficult or repetitive to get done in more "friendly" editors/IDEs like TextMate and Visual Studio.
Janus provided just enough familiarity and convenience to make a full-time swap something I could stick with. After a couple of months of this I did basically dump Janus and start managing plugins myself with Pathogen (adding new ones and removing some of the default Janus ones), and customising my config (which is still based on the old Janus config, but extensively modified)
"Don’t use the NERD tree plugin. It is clumsy, will hurt your workflow with split windows, and it’s not particulary pretty either. You never needed a file browser pane in the first place."
"It is clumsy"
We're talking about VIM, with dozens of keystrokes to invoke everything but emacs already. The whole thing is a bit clumsy! I use it every day and have for a decade but it's still clumsy.
"will hurt your workflow with split windows"
The author then goes on to state
"You can split the current buffer horizontally or vertically. This is useful, for instance, to view simultaneously the top and the bottom part of the same file. But it’s even more useful to view different files in splits; for instance tests and implementation."
HUH?
" and it (nerdtree) ’s not particulary pretty either"
And the rest of VIM is?
Nerdtree is great, especially when I'm using it on remote systems. A vim session open with nerdtree and some tabs inside of a screen session, and life is good.
I'm not a VIM purist. I use the arrow keys, and I use the mouse a lot. I find NERDTree to be tremendously easy to use and helpful when on a local system.
On remote systems, though, I generally just edit 1 file at a time and don't need NERDTree. For multiple files, :e works just fine in those situations.
I toggle nerdtree on and off often, so it's there when I need it, and gone when I don't, so I don't notice it getting in the way of my split windows all that much.
It's also true that Vim 'suffers' from the open source infinite configurability issue. That is, it is so configurable that you'll spend a significant amount of time configuring it to your tastes rather than getting work done. This tails off over time of course. Slightly more awkward is that it's also easy to shoot yourself in the foot. For example my current config has an issue where on rare occasions undo sporadically fails, and ends up undoing line insertions by deleting the wrong line! Ouch. I still have several such issues, but not enough to deter me as yet.
Another thing to consider is that Vim is not equally suited to all developers. If you're editing a bunch of different file types with mostly consistent libraries I think it's a great fit, which describes a lot of web developers. In that case you just want world class text editing. If you're editing mostly C++ with a bunch of different APIs and libraries, the loss of decent codesense/autocomplete forces you into lots of very slow doxygen searching in a browser. I've tried various solutions to this such as clang complete and eclim, but ultimately Vim is not an IDE and there's no way to make it act as one.
Overall I'm happy to have made the switch though, since the editing itself is so very smooth. It's great to have the same environment in a remote shell as well.