Vim: revisited(mislav.uniqpath.com)
mislav.uniqpath.com
Vim: revisited
http://mislav.uniqpath.com/2011/12/vim-revisited/
37 comments
set relativenumber
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 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.
Thanks a lot!
For a vimrc also supporting other version than 7.3:
if version >= 730
set relativenumber
endifI 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>If you ever run into him again, buy him a beer please for Cydia.
(stares in wonder)
I love Jay, seems like a great overall guy.
Thank you for making me aware of this.
Not really sure why the hate for nerdtree.
"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.
"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.
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.
AHHHH - that makes more sense.
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.
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.
I work exclusively in split windows, vertical and horizontal both, and I don't work without NERD Tree anymore.
nnoremap <Leader>n :NERDTreeToggle<CR>
I'm puzzled by why syntastic was so counterproductive for him. It's helped me more times than it's hurt. Does he have autowrite on?
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
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
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)
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.
Same for me. Maybe now I can scrap that and build my own vimrc but having a set of useful plugins really helped me.
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.
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.
I have exclusively used vim as my editor for about 8 years. I'm efficient with it, but there are still many fancy things I don't do. My rule of thumb is this: if I find myself performing a task over-and-over, and being bothered by it, chances are good there's a more efficient way to do it in vim. Then and only then will I look up the better way to do it. Because I'm solving a problem I frequently have, I will learn the new thing.
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.
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.
I have had a lot of trouble remapping Caps Lock on Mac OS X. What's your method?
Prefs -> Keyboard -> Modifier keys.
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.
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.
It's in the keyboard preference pane under "modifier keys".
There's been a bit of anti-mouse talk on here, but I recently took the time to get mouse support on vim in Terminal.app working. I have my notes here: http://www.reasonablyopinionated.com/2011/11/mouse-support-f...
While I do agree using the mouse for cursor positioning isn't always the best use of the mouse, there are situations where it's just better. For instance, using mouse scrolling in vim is very convenient, and mouse selection and paste is also very convenient. It's even better when you can use it across the network!
While I do agree using the mouse for cursor positioning isn't always the best use of the mouse, there are situations where it's just better. For instance, using mouse scrolling in vim is very convenient, and mouse selection and paste is also very convenient. It's even better when you can use it across the network!
I'm happy to have finally gotten comfortable with enough of the movement/editing commands to use them every day for real work. However, I just use Vintage mode in Sublime Text 2 because I like having nice file browsing/tabs and other niceties of Sublime Text 2. Am I missing out on much by not using straight vim?
Yes.
I loved Sublime Text 1, and I really love Sublime Text 2. With the addition of Vintage, Sublime Text is slowly becoming the ultimate answer to the question of which editor to choose.
But Vintage mode is really buggy, and misses a lot of very important features that vim has. There is work being done on it, and it is getting better, but vintage mode does not come close yet to the power of vim. And there are a few bugs that make it hard to get used to some of vim's more powerful features.
I loved Sublime Text 1, and I really love Sublime Text 2. With the addition of Vintage, Sublime Text is slowly becoming the ultimate answer to the question of which editor to choose.
But Vintage mode is really buggy, and misses a lot of very important features that vim has. There is work being done on it, and it is getting better, but vintage mode does not come close yet to the power of vim. And there are a few bugs that make it hard to get used to some of vim's more powerful features.
For me, switching to vim means moving my hand to use the mouse less often, which means less stress on my wrist. Of course, if you're typing on the keyboard all day, you still have some risk for RSI, but I find using the keyboard to be much more comfortable than using the mouse.
Plus it's much more productive!
Plus it's much more productive!
Just as I finally managed to make vim play well with ruby and install CommandT, the (extremely useful) post has been updated with the note about ctrlp.vim. I guess I have no choice except to give it a shot as well. =) (Update: Nope, Command-T seems nicer.)
Every time I read about Vim I feel left off of something huge. Some of the super duper easy shortcuts suggested in this thread translate horribly to AZERTY. For instance ctrl+[ is alt+shift+ctrl+5 on a French Mac or ctrl+altgr+4 on a French PC keyboard.
Currently I'm workign through Python Koans, and decided to use Vim. It's good way to pick up new commands cause you do the same tedious editing keystrokes over and over again, prompting you to look up 'so how do I easily _____ in Vim' as you progress.
This is a incredibly useful overview. My jaw dropped when I read about all the uber-jump commands! I've been setting markers, but this is 100x better. This is exactly why I read every single post about vim, because I always learn something new.
What is this guy's issue with Syntastic?
If he's saying it's not for beginning Vim users, OK, fine. But "harmful plugin"? Like it's some sort of malware? Very poor form.
If he's saying it's not for beginning Vim users, OK, fine. But "harmful plugin"? Like it's some sort of malware? Very poor form.
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.
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 !
Pro tip: after you paste code, it might not be indented correctly in the new context. You can select just pasted lines and autoindent them with V`]=. This should fix the indentation in most cases.
A better alternative: issue the ":set paste" command just before pasting text. That way you keep the original indentation.
A better alternative: issue the ":set paste" command just before pasting text. That way you keep the original indentation.
You can also use a "]" before the "p" (i.e., "]p") to make a new paste follow the existing indentation.
"vim has two main modes, normal mode ... and the insert mode"
i stopped reading here because i knew what was coming next. the omen was fulfilled by the next line:
"in insert mode, now you type text as your normally would. Pressing <Esc> exits back to normal mode."
its command mode vs insert mode. any vi user should know that.. it's the very first thing vi bludgeons you with.
i stopped reading here because i knew what was coming next. the omen was fulfilled by the next line:
"in insert mode, now you type text as your normally would. Pressing <Esc> exits back to normal mode."
its command mode vs insert mode. any vi user should know that.. it's the very first thing vi bludgeons you with.
Still can't decide if Vim is actually worth all this trouble, or if it's a cult.
When considering the 'classics'; it's either joining the cult of vim, or entering the church of emacs.
Both have pros and cons; both are in the same everlasting-holy-war and once in a while either will start a new crusade.
Both have pros and cons; both are in the same everlasting-holy-war and once in a while either will start a new crusade.
You've gotta manage your expectations properly. Vim takes time to learn. Trust that there's a payoff, be patient. I'd like to think my first attempt at becoming a Vim user stuck, but I took it slow. I was using Vim at my day job, and it went something like this:
1 month - really started to feel a productivity increase over text editing in an IDE
3 months - started to feel like I was flying
6 months - began desperately searching for Vim plugins for Eclipse
1 month - really started to feel a productivity increase over text editing in an IDE
3 months - started to feel like I was flying
6 months - began desperately searching for Vim plugins for Eclipse
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.
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:
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
:colorscheme<space><tab>
And if you're not satisfied by any of existing Vim color schemes you can always convert bunch of Textmate ones here: http://ku1ik.com/2011/10/22/coloration-vim-256-colors.html
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!"
Fair enough. I'm currently using Freya since I have a love of low contrast dark schemes with muted colours.
http://www.vim.org/scripts/script.php?script_id=1651
http://www.vim.org/scripts/script.php?script_id=1651
Also, colorschemes are supposed to set the colors_name variable:
:let colors_name
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.
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.
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.
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.
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.
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.
Time to remap that one too.
Time to remap that one too.
I don't see any problem with using the arrow keys.
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.
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.
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.
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.
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.
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.
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.
I would second this. Managing with pathogen is really finicky and a huge timesink if you screw things up.
The newer versions of Vundle are fantastic, and give you features like lists of your current plugins and searching of the plugins repository.
The newer versions of Vundle are fantastic, and give you features like lists of your current plugins and searching of the plugins repository.
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.
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?
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.
The stories aren't the same, though.
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.
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.
[deleted]
One of the best tutorials, to get started with Vim, I've seen around. Well done.
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.
> I think I just need to take a weekend and learn enough vim programming to make it happen as a Nerd Tree plugin.
Check out Steve Losh's Learn Vimscript the Hard Way[1].
[1] http://learnvimscriptthehardway.stevelosh.com/
Check out Steve Losh's Learn Vimscript the Hard Way[1].
[1] http://learnvimscriptthehardway.stevelosh.com/
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.
I pretty happy to have learned about <C-^> and `. I always learn something from these 'how I learned vim' articles.
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.
"And if you did multiple jumps, you can backtrack with <C-o>."
I learn something new with these posts every time! I've been wanting something like this for a while.
I learn something new with these posts every time! I've been wanting something like this for a while.
And you can use Tab to go forward.
If you have tab bound to something else (c-p here), then c-i will do the same.
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'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 agree about accepting (most) standard key bindings, but here are two clever bindings I adopted:
" Enter command mode with SPACE instead of :
noremap <Space> :
" Exit insert mode with jj (double J) instead of ESC
imap jj <Esc>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)
Note: that isn't exactly the same--using Esc will trigger InsertLeave autocommands, Ctrl-C will not.
imap <c-c> <esc>
Now it does.
Now it does.
As graywh says, ctrl-c is not the exact same as escape. If you want something standard which is, try ctrl-[. Harder to type, I know.
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.
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 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.
* 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.
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.
Hence, your question is somewhat misguided ;)
Hence, your question is somewhat misguided ;)
And what country is your keyboard from?
Unless you mean you specifically use search for every motion...?
Unless you mean you specifically use search for every motion...?
I use colemak now, but this holds true in qwerty as well (most of the time). I don't use search for EVERYTHING, just most of the time it's faster.
don't forget about:
let mapleader = ","
I use backspace as a substitute for ESC. I find ESC awkward to locate while typing, but backspace is easy.
Hi, no need for remapping of any keys if you are after Esc. Just type Control-[, it generates Esc by default.
Literally typing Ctrl+[ works for escape by default, it's what I've been doing instead of trying to remap keys.
my one indispensable plugin is matchit.vim, which does % matching between paired tokens like do/end, or <div>/</div>
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.
If you touch-type, keeping fingers on the home row is essential. So, yes, it's a huge waste.
+1 But I remapped the movement keys to j/k/l/; to avoid moving my left-index finger.
Same here, actually. Although in dvorak, they're htns :)
Yes, absolutely. This hjkl navigation (combined with other vim code motions) you can really fly are files.
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.
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.
Add the following to your .vimrc
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
map <up> <nop>
map <down> <nop>
map <left> <nop>
map <right> <nop>
imap <up> <nop>
imap <down> <nop>
imap <left> <nop>
imap <right> <nop>
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.
And then your arrow keys are free to bind to something else useful, like moving between split windows, buffers, etc.
Spaced repetition fans should be aware that there's a great Anki deck available for learning vim commands:
http://alfmikula.blogspot.com/2010/11/using-spaced-repetitio...
http://alfmikula.blogspot.com/2010/11/using-spaced-repetitio...
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.