Two Simple Steps Helped Me Learn Vim(adamdelong.com)
adamdelong.com
Two Simple Steps Helped Me Learn Vim
http://adamdelong.com/two-simple-steps-helped-me-learn-vim/
91 comments
I sprung for the paid version, and have progressed part of the way through the last level. Compared to the demo, I think that it helped with some more advanced features, but mostly just made me aware of them rather than giving me the proficiency I learned with the basic commands. Perhaps if I repeated the game, I'd become more natural with them.
Still, highly recommended. It's been a lot of fun to play, and it helped me to quickly become proficient.
Still, highly recommended. It's been a lot of fun to play, and it helped me to quickly become proficient.
The biggest thing that helped me was when I realized that it actually all makes sense.
Every time you use vim and catch yourself repeating a command over and over (x, dd, hjkl) take a moment and think about if there is a more efficient way to do it by combining the commands you know.
Let's say you need to delete everything from you current cursor position to the next paren in the current line, ok you know that:
t -> move till char x in the current line
T -> move till previous char x in the current line
d -> delete
so you can combine that to:
dt( -> delete everything till next ( in line
Delete 10 lines, instead of 10 times "dd" you can just do: 10dd
Go from line 0 to line 20, instead of pressing j 20 times: 20G
Delete from current position to line 20: d20G
These are all really simple examples, but once you get the hang of it you move on to more complex stuff in no time, and you probably won't even have to look it up, it will just make sense.
Every time you use vim and catch yourself repeating a command over and over (x, dd, hjkl) take a moment and think about if there is a more efficient way to do it by combining the commands you know.
Let's say you need to delete everything from you current cursor position to the next paren in the current line, ok you know that:
t -> move till char x in the current line
T -> move till previous char x in the current line
d -> delete
so you can combine that to:
dt( -> delete everything till next ( in line
Delete 10 lines, instead of 10 times "dd" you can just do: 10dd
Go from line 0 to line 20, instead of pressing j 20 times: 20G
Delete from current position to line 20: d20G
These are all really simple examples, but once you get the hang of it you move on to more complex stuff in no time, and you probably won't even have to look it up, it will just make sense.
This is precisely why I love vim. It's like *nix. Small parts come together to make the whole a lot more better. I struggled quite a bit with vim. But once I read this stackoverflow answer, it all made sense!
http://stackoverflow.com/questions/1218390/what-is-your-most...
http://stackoverflow.com/questions/1218390/what-is-your-most...
Yes, but there's a difference between "makes sense" and "I can do it without thinking, so it is a lot faster than pressing ctrl + right arrow a few times" which then leads to "maybe I'll use vim instead of Sublime Text after all." :)
Everything takes time to master, but understanding/being able to make sense of something makes a big difference.
You just started learning vim and are moving around with hjkl and x-ing words letter by letter, then you learn about moving with w/W and b/B and repeating/combining commands (2w, 2b, ...), and the next time you're using it you think "wait a minute, d is delete, I use dd all the time, why wouldn't I just d2w to delete those 2 words, huh, it didn't work right, the cursor is in the middle of the first word, I have to bd2w", at least that's somewhat how I first started getting it. Once you understand something it's hard to forget and after a short time using it you don't really need think about it like you mentioned.
You just started learning vim and are moving around with hjkl and x-ing words letter by letter, then you learn about moving with w/W and b/B and repeating/combining commands (2w, 2b, ...), and the next time you're using it you think "wait a minute, d is delete, I use dd all the time, why wouldn't I just d2w to delete those 2 words, huh, it didn't work right, the cursor is in the middle of the first word, I have to bd2w", at least that's somewhat how I first started getting it. Once you understand something it's hard to forget and after a short time using it you don't really need think about it like you mentioned.
I turned my junior engineer colleague with zero vim experience on to Vim Adventures last week. She took to it right away, got up to level 12, and taught a class at our hackersspace on intro to vim last night, during which I learned a bunch of new commands myself. Vim Adventures is fun and vastly more engaging than vimtutor - well worth the price.
Time and again, these "how to coerce yourself into learning this hostile tool called vim" posts appear. I read them, and it sparks my interest.
But usually, whats missing is part 2, which goes: "... and this is why it was so totally worth it". An no, just because it works over SSH and is installed on every server is not quite sufficient.
Also, are you programming in a script language or a .NET or JVM behemoth?
But usually, whats missing is part 2, which goes: "... and this is why it was so totally worth it". An no, just because it works over SSH and is installed on every server is not quite sufficient.
Also, are you programming in a script language or a .NET or JVM behemoth?
"... and this is why it was so totally worth it".
This is something that is difficult to explain, but absolutely clear to you once you have achieved some degree of efficiency.
Muscle memory makes the editor disappear and let you focus, not on the keyboard, not on the menus, but on code itself.
I suggest you watch some live-coding videos of people very experienced in the editor to get an idea (in this case the programmer uses emacs, but the concept is the same):
https://www.youtube.com/user/handmadeheroarchive
This is something that is difficult to explain, but absolutely clear to you once you have achieved some degree of efficiency.
Muscle memory makes the editor disappear and let you focus, not on the keyboard, not on the menus, but on code itself.
I suggest you watch some live-coding videos of people very experienced in the editor to get an idea (in this case the programmer uses emacs, but the concept is the same):
https://www.youtube.com/user/handmadeheroarchive
Do you know what is the guy using within VS here? Is this an Emacs extension or something added on top. He seems to be going full screen and switching files very quickly. I've seen this before on someone's machine but didn't ask about it. I don't know anything about emacs myself.
I'm a vim guy, but the strength of emacs is that is basically running on its own lisp, so it's completely programmable.
He's likely to be running a customized version.
He's likely to be running a customized version.
I had/have to use vim almost every day (a lot of it was managing headless servers, but also being a linux user myself), and it was somewhat of a pita every time I used it, but a bit less so than nano, pico or what have you.
After some time I finally had enough and decided to invest some time in figuring it out mostly in the hope of making it a bit less of a pita. Also, so many people seemed to just love using vim. Makes you think that it may not be the most pointless thing in the world to invest some time in.
What I got from it personally is:
Most text editors now feel like there's not much to them, you rote learn the editor specific shortcuts, but they often don't have any meaning on their own so there is a tendency to forget them when they aren't used every day. Luckily the ones used most are often somewhat consistent across editors so it doesn't take much time to get to some level of proficiency with a new editor. Also you often have to use your mouse and sometimes arrow keys for efficient movement and text selection. This requires constantly moving one of your hands out of the typing position which seems a lot more distracting if you get somewhat used to "mouseless" text editing.
With vi(m), yes, you have to learn the shortcuts/commands but they kind of add together, almost every command or way to do something seems not only useful by itself but also expands your vocabulary and enables you to tell the editor what it should do in a more efficient way. In a way you are making up shortcuts on the fly all the time by composing commands you know depending on what you want to do, only most of the time (at least while editing text) you don't actually think about commands or shortcuts just like you don't have to think about ctrl+x and ctrl+v, it's just select, cut, paste.
tl;dr, my opinion
Is it worth spending the time and effort given the steep learning curve? If you don't already use vim at least some of the time and would have to force yourself into using it, I personally would say no. I think I still would have tried it but I don't know if I would have stuck with it once the novelty had worn off. I wasn't really unhappy with text editors, I just didn't like using vim the way I was using it. Also you end up adding "vim mode" plugins to every damn thing you type text into, IDE's (used for those behemoths), other text editors, web browsers, ...
What I got from it personally is:
Most text editors now feel like there's not much to them, you rote learn the editor specific shortcuts, but they often don't have any meaning on their own so there is a tendency to forget them when they aren't used every day. Luckily the ones used most are often somewhat consistent across editors so it doesn't take much time to get to some level of proficiency with a new editor. Also you often have to use your mouse and sometimes arrow keys for efficient movement and text selection. This requires constantly moving one of your hands out of the typing position which seems a lot more distracting if you get somewhat used to "mouseless" text editing.
With vi(m), yes, you have to learn the shortcuts/commands but they kind of add together, almost every command or way to do something seems not only useful by itself but also expands your vocabulary and enables you to tell the editor what it should do in a more efficient way. In a way you are making up shortcuts on the fly all the time by composing commands you know depending on what you want to do, only most of the time (at least while editing text) you don't actually think about commands or shortcuts just like you don't have to think about ctrl+x and ctrl+v, it's just select, cut, paste.
tl;dr, my opinion
Is it worth spending the time and effort given the steep learning curve? If you don't already use vim at least some of the time and would have to force yourself into using it, I personally would say no. I think I still would have tried it but I don't know if I would have stuck with it once the novelty had worn off. I wasn't really unhappy with text editors, I just didn't like using vim the way I was using it. Also you end up adding "vim mode" plugins to every damn thing you type text into, IDE's (used for those behemoths), other text editors, web browsers, ...
I first saw Vim in use back in 2000. I was working at NuMega (Compuware lab at the time) and I was a Windows only user that was just starting to get very comfortable with the DOS prompt and I used Notepad for any editing that wasn't done in Visual Studio.
I had some huge file in which I had to do a bunch of refactoring. Some search and replace, and some reorganization.
I had been plodding away, copying, pasting, and repetitively hitting the arrow keys and typing a few characters in each place for about 5 minutes when a friend came over and saw what I was doing. He was an absolute *nix expert. After a few moments, he told me that he could finish all those changes in just a minute. I had seen him code in Vim before, and was impressed, but it seemed like magic at the time. I saved the file and went over to his desk and asked him to walk me through exactly what he was going to do. He loaded the file up in Vim and started with a quick regex that knocked out 80% of the work. He then recorded a macro that yanked the current counter number into a buffer, searched for the next edit position, pasted in the counter number, incremented it, then shifted position to the next code block and updated that reference as well. He then asked me about how many sections there were. I said about a hundred, so he typed 99@q and poof! There were a few more, so he did a :g/<some keyword>/p to see how many lines there were and then did that many more macro invocations and the file was done.
I was hooked at that point. He set me up with gVim and some tutorials and taught me the most basic fundamentals and told me that it didn't matter if I couldn't make vimgolf par for the first year or so. If I used it and every once in a while picked up a new motion or command, after a few years, it would change my coding life.
He was right.
I had some huge file in which I had to do a bunch of refactoring. Some search and replace, and some reorganization.
I had been plodding away, copying, pasting, and repetitively hitting the arrow keys and typing a few characters in each place for about 5 minutes when a friend came over and saw what I was doing. He was an absolute *nix expert. After a few moments, he told me that he could finish all those changes in just a minute. I had seen him code in Vim before, and was impressed, but it seemed like magic at the time. I saved the file and went over to his desk and asked him to walk me through exactly what he was going to do. He loaded the file up in Vim and started with a quick regex that knocked out 80% of the work. He then recorded a macro that yanked the current counter number into a buffer, searched for the next edit position, pasted in the counter number, incremented it, then shifted position to the next code block and updated that reference as well. He then asked me about how many sections there were. I said about a hundred, so he typed 99@q and poof! There were a few more, so he did a :g/<some keyword>/p to see how many lines there were and then did that many more macro invocations and the file was done.
I was hooked at that point. He set me up with gVim and some tutorials and taught me the most basic fundamentals and told me that it didn't matter if I couldn't make vimgolf par for the first year or so. If I used it and every once in a while picked up a new motion or command, after a few years, it would change my coding life.
He was right.
I think that it is necessary to learn Vim not because it is the best text editor (it's not!), but because it is one of the best ways to edit texts.
It was hard for me to get used to it (I forced myself to write all scripts - Perl, Bash etc. - in Vim). But it was absolutely worth it. Now I use vim mode in browser, in huge Java IDE (Idea), in file manager etc.
Vim (as an editor) has many disadvantages (Google it). But it is a superior way to edit texts. I switched to Emacs recently (for LISP-coding), but immediately downloaded Evil package. Now I have best from both worlds :)
Yes, I use Emacs, but my love is Vim.
My point is: all text editors are just tools. But try to learn Vim way to edit texts.
It was hard for me to get used to it (I forced myself to write all scripts - Perl, Bash etc. - in Vim). But it was absolutely worth it. Now I use vim mode in browser, in huge Java IDE (Idea), in file manager etc.
Vim (as an editor) has many disadvantages (Google it). But it is a superior way to edit texts. I switched to Emacs recently (for LISP-coding), but immediately downloaded Evil package. Now I have best from both worlds :)
Yes, I use Emacs, but my love is Vim.
My point is: all text editors are just tools. But try to learn Vim way to edit texts.
Interesting - so IDE + Vim mode would be the best of both worlds. Do you find there is a lot lost in translation, or does that feeling carry over well? I'd be especially interested in Emacs and IDEA.
I've typically found that vim impersonations miss at least a couple features that I use regularly. I've heard that Evil, in particular, is pretty complete though.
Evil is the first Vi/Vim emulation package that didn't frustrate me pretty intensely with things that didn't quite work as expected coming from Vim.
However, it doesn't attempt to turn Emacs into Vim, it's more like it gives Emacs an acceptable Vi interface for the places where that matters.
As a result, if you are using both Vim and Emacs contemporaneously, it's still easy to develop habits in one, that will cause you pain in the other.
For example, because Evil still allows you to do a lot of Emacs shortcuts, and because :q kills Emacs if there's only one window open, I find myself doing C-x k a lot to git rid of buffers.
However, that causes huge pain when I accidentally do that when I'm back in Vim. Instead I should really get in the habit of using :bd to get rid of buffers, but that's one aspect of Vim that I've never fully moved to from using naive vi style :q.
However, it doesn't attempt to turn Emacs into Vim, it's more like it gives Emacs an acceptable Vi interface for the places where that matters.
As a result, if you are using both Vim and Emacs contemporaneously, it's still easy to develop habits in one, that will cause you pain in the other.
For example, because Evil still allows you to do a lot of Emacs shortcuts, and because :q kills Emacs if there's only one window open, I find myself doing C-x k a lot to git rid of buffers.
However, that causes huge pain when I accidentally do that when I'm back in Vim. Instead I should really get in the habit of using :bd to get rid of buffers, but that's one aspect of Vim that I've never fully moved to from using naive vi style :q.
I think a great answer to this question is in this stack overflow answer: http://stackoverflow.com/questions/1218390/what-is-your-most...
To answer you second question: yes. I've done quick scripts and giant programs in vim. Also note: I use full IDEs in conjunction with vim where appropriate - I mean, why wouldn't I take advantage of Visual Studio when doing C#, but even then I still regularly drop into Vim (because of the stuff in the above link).
To answer you second question: yes. I've done quick scripts and giant programs in vim. Also note: I use full IDEs in conjunction with vim where appropriate - I mean, why wouldn't I take advantage of Visual Studio when doing C#, but even then I still regularly drop into Vim (because of the stuff in the above link).
For me, I was always annoyed with how tedious it was to edit things. i.e, The gap between what I think vs what I have to do in the editor to get it done. This constant annoyance was what drove me to spend time and energy into learning it. I believe that if you don't care about it, you won't really benefit out of it. Because the whole point of switching to Vim/Emacs is to minimise the gap between what you think and how you do it.
Let me give you an example. You'll be thinking, "I need to change all the arguments to a function." In other editors, you'll press the arrow keys until you get to one end, press backspace key multiple times until you get to the other end. In Vim, I'd do "ci(" which means "change everything inside (" - which is pretty much how I think about what I need to do. A similar but more common example is changing text inside quotes. Again, that'd be 'ci"'.
Not everyone feels the annoyance about this and if you don'tt, hats totally fine. Learning something just because its cool is never worth it. Learn it if you really care about it.
Also read this post by Yehuda Katz about how he started for some ideas. http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...
Let me give you an example. You'll be thinking, "I need to change all the arguments to a function." In other editors, you'll press the arrow keys until you get to one end, press backspace key multiple times until you get to the other end. In Vim, I'd do "ci(" which means "change everything inside (" - which is pretty much how I think about what I need to do. A similar but more common example is changing text inside quotes. Again, that'd be 'ci"'.
Not everyone feels the annoyance about this and if you don'tt, hats totally fine. Learning something just because its cool is never worth it. Learn it if you really care about it.
Also read this post by Yehuda Katz about how he started for some ideas. http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...
Your example falls flat. Any text editor with regular expression support can do that...
Do you have another example?
Do you have another example?
I think you are missing the elegance. The example isn't change foo to bar in f1(foo); f2(foo); f3(foo). The example is the series of steps and physical mode changes to change f(foo) to f(bar).
To do this one must select the letters foo somehow and then cause bar to be typed in their place. This can be done a number of ways in a "normal" text editor. For example, the person might double-click foo with the mouse to select the word and then type in bar. This does four things: 1. places the cursor in the location of foo; 2. select foo; 3. remove foo; 4. insert bar. In this example, there is one or two physical input context changes: from keyboard to mouse and back or maybe just from mouse to keyboard.
In vim, the physical input context never changes. The keyboard remains your context throughout. The person would 1. Position the cursor somewhere by foo (i.e. by typing a search expression like /foo<enter>); 2. type ci(<enter> which selects everything in the parenthesis, deletes and changes the context to input; 3. type bar (and probably 4. press the <esc> key).
I suspect that some people aren't bugged very much by the physical context switch and so the point of this is lost. Other people are bugged by it and struggle along until they find vi, emacs or the like.
To do this one must select the letters foo somehow and then cause bar to be typed in their place. This can be done a number of ways in a "normal" text editor. For example, the person might double-click foo with the mouse to select the word and then type in bar. This does four things: 1. places the cursor in the location of foo; 2. select foo; 3. remove foo; 4. insert bar. In this example, there is one or two physical input context changes: from keyboard to mouse and back or maybe just from mouse to keyboard.
In vim, the physical input context never changes. The keyboard remains your context throughout. The person would 1. Position the cursor somewhere by foo (i.e. by typing a search expression like /foo<enter>); 2. type ci(<enter> which selects everything in the parenthesis, deletes and changes the context to input; 3. type bar (and probably 4. press the <esc> key).
I suspect that some people aren't bugged very much by the physical context switch and so the point of this is lost. Other people are bugged by it and struggle along until they find vi, emacs or the like.
Pepole don't use vim because it does things that are simply impossible in other editors - they use it because they find it lets them do that thing better. In this case, I guess the main point is about vim's modal editing in which the command is simple, easy to type and obeys a meaningful grammar.
vim:
step 1: type ci(. step 2: type what you want to replace with. step 3: press ESC.
notepad++:
step 1: press Ctrl-H. step 2: type \([^)]*\). step 3: press tab. step 4: press (. step 5: type what you want to replace with. step 6: press ). step 7: move hand to mouse. step 8: move cursor to and click on "Regular expression". step 9: press enter.
Do you have another example?
step 1: type ci(. step 2: type what you want to replace with. step 3: press ESC.
notepad++:
step 1: press Ctrl-H. step 2: type \([^)]*\). step 3: press tab. step 4: press (. step 5: type what you want to replace with. step 6: press ). step 7: move hand to mouse. step 8: move cursor to and click on "Regular expression". step 9: press enter.
Do you have another example?
Not implying that the vim way isn't faster but on any regular text editor you can:
ctrl+right arrow once or twice, right arrow to skip the (, shift+end, shift+left arrow, then type.
ctrl+right arrow once or twice, right arrow to skip the (, shift+end, shift+left arrow, then type.
And of course, \([^)]*\) breaks if you have foo(bar(), x / (y + 1))
The reason why it's interesting is it is basically a grammer for editing text. It's simple enough that you can easily create new strings of grammar which do what you want but powerful enough that the skill ceiling is practically infinite. Once you have a grammar for editing text a lot of interesting features fall into place quite naturally like having 'undo trees' instead of just linear undo, being able to write complex macros in the same language you edit text in, etc...
The ssh/server thing you noted is what got me; being able to search and navigate in really large log files on the cluster I used to work on. That was my gateway drug. I don't use it full time, but I use it quiet a bit now.
It's worth it for the same reason dvorak is worth it (to those who master it.)
Mandatory XKCD: http://xkcd.com/561/
A more elegant solution than a notecard may be using a vim cheatsheet wallpaper, like this:
http://vimfoo.com/2012/09/vim-shortcut-wallpaper/
The downside of that is that it isn't customizable, so I get why he likes the 3x5 card. But at least you can't lose this.
http://vimfoo.com/2012/09/vim-shortcut-wallpaper/
The downside of that is that it isn't customizable, so I get why he likes the 3x5 card. But at least you can't lose this.
Notably that only features the movement commands. But by limiting the scope it allows for a remarkably intuitive layout that helps put everything in context.
Thanks for the link!
Thanks for the link!
"Awesome! With my vim cheat sheet wallpaper I will never forget anything! This time next year, Rodney..."
<opens large vim window>
"Oh..."
<opens large vim window>
"Oh..."
Konsole with transparent background or set the wallpaper as background...
+5 points for using that reference on Hacker News.
Here are some more tips:
- disable arrow keys
- turn relative numbers on by default
- force yourself to only move vertically using relative numbers
- force yourself to only move horizontally using [fF,;]Good tips. Getting in the habit of explicitly searching (/) instead of scrolling is another one.
On the subject of using fFtT (and other motions), there's a plugin I quite like that works well with my mental model of that motion—I often don't want to go to the first instance of that character, but the second or third in that line. EasyMotion[1] lets you do that.
[1] https://github.com/Lokaltog/vim-easymotion
On the subject of using fFtT (and other motions), there's a plugin I quite like that works well with my mental model of that motion—I often don't want to go to the first instance of that character, but the second or third in that line. EasyMotion[1] lets you do that.
[1] https://github.com/Lokaltog/vim-easymotion
> - force yourself to only move vertically using relative numbers
> - force yourself to only move horizontally using [fF,;]
I'm finally learning and remembering to use marks which are another great way to navigate a buffer or even several buffers at once.
- disable arrow keys
- force yourself ...
- force yourself ...
The moment you start with Vim you're diving in the deep end and productivity will take a plunge. At least training wheels like the arrow keys can help you stay productive and keep using it for long enough until you cross over the productivity threshold (where you're more productive than on a normal editor, even though you still have a lot more learning to do).
Agreed - I use vim heavily and also use arrow keys (when I can) and when they do not work for whatever reason i fall back to HJKL.
For me my main blocker was just purely not being able to use it for the absolute basic operations. I found that once I learned how to do the absolute basic (insert, copy, paste, move around, search, etc.) I was able to use vim. The next step was building my own vimrc with some very basic configurations that made vim much easier to use. Then whenever I need or want to do something complicated I just google for the command, plugin, or write my own plugin.
For me my main blocker was just purely not being able to use it for the absolute basic operations. I found that once I learned how to do the absolute basic (insert, copy, paste, move around, search, etc.) I was able to use vim. The next step was building my own vimrc with some very basic configurations that made vim much easier to use. Then whenever I need or want to do something complicated I just google for the command, plugin, or write my own plugin.
Arrows are just another way of jumping, this is not Unix VI, this is VIM
It's an editor, it should be as easy as possible. People (should) use VIM because it's powerful, not because it's different from other editors.
It's an editor, it should be as easy as possible. People (should) use VIM because it's powerful, not because it's different from other editors.
Good tips! You just reminded me that I did both of those first two at first as well. Arrows especially. But those last two are good too! I'll have to add them into my workflow.
I think disabling the arrow keys is a mistake for someone just coming to vim. The arrow keys can act as a warm blanket of familiarity while learning the harsh winter of vim. When a noob is making mistakes and getting frustrated having the arrow keys work like normal is a comforting reprieve.
Once someone has a couple of months of vim under their belt then would I recommend disabling the arrow keys.
Once someone has a couple of months of vim under their belt then would I recommend disabling the arrow keys.
Why would you want to disable arrow keys?
To to keep your fingers on the home row, in order to have better access to all the other keys in your keyboard.
Having your fingers on the arrow keys mean your hand has to travel that much further to type the other keys—making you slower.
Having your fingers on the arrow keys mean your hand has to travel that much further to type the other keys—making you slower.
I've always wondered if the "disable the arrow key" advice given to every VIM novice makes any sense for the user of a 11" - 13" laptop. It was probably a good advice for a classical keyboard, but I find the arrow keys quite handy when I work on a small laptop keyboard.
I started seriously using vim around the time I started coding on the go with a very old eeePC (the first model, the absurdly small one). This was around 5-6 years ago probably. Back then I had already used vim before but only as a "normal" text editor, just go into insert mode and move around with arrows.
I was forced to use vim because that old piece of crap PC (I still love it though) wasn't powerful enough to run anything, really, and the screen was super small. I noticed using arrows key was super uncomfortable because yes, they were closer to the actual home row but they were also smaller, clunkier and harder to press. So I decided to force myself to use hjkl and disable arrow keys. It was definitely one of the best decisions of my (coding) life. Just comfortably resting your hands on the home row (either laptop keyboard or normal one) simply makes your typing more relaxed and after the couple of weeks (months?) struggling with left/right (up and down was fairly easy) you really stop noticing it.
Funnily enough, I re-enabled arrow keys a year or so ago and I haven't really felt the temptation to use them anymore.
DISCLAIMER: This turned me into a super slow and awkward typist when I am trying to work on text in an editor that does not support vim mode (like google docs for example). I have several documents around with jjjkkjhjjhjjllljh unfortunately.
I was forced to use vim because that old piece of crap PC (I still love it though) wasn't powerful enough to run anything, really, and the screen was super small. I noticed using arrows key was super uncomfortable because yes, they were closer to the actual home row but they were also smaller, clunkier and harder to press. So I decided to force myself to use hjkl and disable arrow keys. It was definitely one of the best decisions of my (coding) life. Just comfortably resting your hands on the home row (either laptop keyboard or normal one) simply makes your typing more relaxed and after the couple of weeks (months?) struggling with left/right (up and down was fairly easy) you really stop noticing it.
Funnily enough, I re-enabled arrow keys a year or so ago and I haven't really felt the temptation to use them anymore.
DISCLAIMER: This turned me into a super slow and awkward typist when I am trying to work on text in an editor that does not support vim mode (like google docs for example). I have several documents around with jjjkkjhjjhjjllljh unfortunately.
It's not so much about speed. It's about comfort.
I would argue that it's best to disable arrow keys in insert mode only. This is the real problem here. By using arrow keys in insert mode, the novice ends up using vim just like a glorified notepad, and never truly understanding the different modes. Since they aren't ever going back to command mode, they never consider using more advanced movement operators, and then they never realize the power of composing motions and commands.
Whenever I start teaching someone vim, I always add this to their .vimrc:
Whenever I start teaching someone vim, I always add this to their .vimrc:
inoremap <Left> <nop>
inoremap <Right> <nop>
inoremap <Up> <nop>
inoremap <Down> <nop>
[deleted]
I've always wanted to learn vim, as so many great coders use it and swear by it, and it doesn't seem fundamentally harder than any other power-user skill. My biggest fear is that I work with novices (who are using something like Sublime) on a regular basis, and it's more friction than it's worth to switch between the two kinds of muscle memories.
Also...maybe I don't write/edit enough code to justify learning vim? I mean, both measured in lines and in number of projects. I'd like to think I've advanced to the point where I'm spending 95% of my time thinking and 5% of my time actually typing in code...being able to quickly grep and navigate through Sublime Text is definitely a vital asset, but I'm not sure how much vim will add to my overall efficiency.
Also...maybe I don't write/edit enough code to justify learning vim? I mean, both measured in lines and in number of projects. I'd like to think I've advanced to the point where I'm spending 95% of my time thinking and 5% of my time actually typing in code...being able to quickly grep and navigate through Sublime Text is definitely a vital asset, but I'm not sure how much vim will add to my overall efficiency.
I agree that an advanced developer spends very little time actually typing, and I think knowing some of the more advanced vim commands can help cement that. Visual block mode and command-limited search and replace in particular are vital features for a software developer, when so many of the code changes that need to be made are similar in multiple locations.
If you have tools that work for you I don't see a reason to change. I use vim because it's a great editor, can run in a terminal, and is open source. I know the producer won't go out of business.
Ah yes...the ability to use in a terminal is a huge thing. That ubiquity was not important to me a year ago, but now I'm at a Unix shell so often that I most definitely feel the pain of doing quickie scripting via nano/pico. Hmm, I think you've convinced me :)
Interesting post!
I found another way to improve my vim skills and memory was to simply write a wiki page with all the shortcuts / key strokes I learned or used. It has a big benefit for me of anchoring things in my memory.
Always having it open when in vim, referring to it often, adding things, moving things, reorganizing categories was a huge benefit for me.
Here is a screenshot of my wiki page index:
http://imgur.com/my7lJJG
Also, having ones' dotfiles synced on github can be highly beneficial as your vim env / plugins will be consistent between desktop / laptop / office / friends' place.
[Edit] - cosmetics
I found another way to improve my vim skills and memory was to simply write a wiki page with all the shortcuts / key strokes I learned or used. It has a big benefit for me of anchoring things in my memory.
Always having it open when in vim, referring to it often, adding things, moving things, reorganizing categories was a huge benefit for me.
Here is a screenshot of my wiki page index:
http://imgur.com/my7lJJG
Also, having ones' dotfiles synced on github can be highly beneficial as your vim env / plugins will be consistent between desktop / laptop / office / friends' place.
[Edit] - cosmetics
Would you be willing to share the HTML for your wiki page?
Just looking at the table of contents, it seems really useful for those of us trying to learn vim compared to the normal cheat sheet that looks like a periodic table...
Just looking at the table of contents, it seems really useful for those of us trying to learn vim compared to the normal cheat sheet that looks like a periodic table...
Sure! Here it is:
http://pastebin.com/BbJv6sWX
It's raw HTML, sorry for the format :)
Note that I have the same kind of stuff for everything linux related:
http://imgur.com/fI12YY5
http://pastebin.com/BbJv6sWX
It's raw HTML, sorry for the format :)
Note that I have the same kind of stuff for everything linux related:
http://imgur.com/fI12YY5
Great, thanks!
There is finally a good 'first' book about learning Vim, that just came out this week: Pro Vim
www.amazon.com/Pro-Vim-Mark-McDonnell/dp/1484202511/
He sets you up with a reasonable .vimrc to start, which I think it key to get over the bad defaults. He starts at the beginning, and takes you well beyond what vimtutor covers.
I'm working my way through it now.
I'd also suggest vimcheatsheet.com, for something to hang on the wall. I just don't get the cheatsheets that have a keyboard, since I don't really think about the location of the keys I'm typing.
www.amazon.com/Pro-Vim-Mark-McDonnell/dp/1484202511/
He sets you up with a reasonable .vimrc to start, which I think it key to get over the bad defaults. He starts at the beginning, and takes you well beyond what vimtutor covers.
I'm working my way through it now.
I'd also suggest vimcheatsheet.com, for something to hang on the wall. I just don't get the cheatsheets that have a keyboard, since I don't really think about the location of the keys I'm typing.
Considering that learning Emacs is comparably hard as learning Vim I think that second advice is not always right, especially when the pet project is developed in language you're learning and not familiar with - which is often the case. It's often hard to learn new keybindings, new syntax, new workflow, new idioms and maybe even new paradigm. Sometimes it's simply too much for evening time, when I want to do something for pleasure.
I've been using vim pretty much full time since around 2000. The one important thing to accept about it: you'll never know all of it. It's just huge. (but you'll never know all of any big dev environment - such is the life of a software dev). To get really good with it, after the basics, I just kept (and still do) in mind that "there's probably a better/easier/faster way to do this". Then roughly once a quarter I'll spend an afternoon figuring out how to do something new, and consciously focus on incorporating it into my workflow. Just like I would with any other tool or technique.
Just because it's "old school stuff like vim" doesn't mean it isn't worth learning. I don't know how it's viewed so differently than say, learning how to use containers, or learning how to do event based programming, or any other concept that slows you down for a little before making you more productive.
Just because it's "old school stuff like vim" doesn't mean it isn't worth learning. I don't know how it's viewed so differently than say, learning how to use containers, or learning how to do event based programming, or any other concept that slows you down for a little before making you more productive.
For me, mapped caps lock to escape and thereafter never looked back. I found reaching to the top left of my keyboard was breaking my concentration. Especially given I touch type.
Also visualbell is almost mandatory otherwise "beep mode" was enough to drive me crazy.
Also visualbell is almost mandatory otherwise "beep mode" was enough to drive me crazy.
I have been meaning to learn Vim for a while but everytime I was trying I ended up being overwhelmed by the number of command (and also frankly, the weird syntax of .vimrc).
I finally took a step by step approach and started with a very minimal .vimrc and worked my way up from there, solving real problems I ran into. I think the key is to choose your battle.
Also this helped me understand the core concepts of how Vim operates: https://pragprog.com/book/dnvim/practical-vim
I finally took a step by step approach and started with a very minimal .vimrc and worked my way up from there, solving real problems I ran into. I think the key is to choose your battle.
Also this helped me understand the core concepts of how Vim operates: https://pragprog.com/book/dnvim/practical-vim
One thing to remember about your .vimrc file is that it's just a list of commands. What's the command to expand tabs? :set et. And the corresponding .vimrc setting? set et.
One fun thing to do to a friend is echo q >> ~/.vimrc.
One fun thing to do to a friend is echo q >> ~/.vimrc.
That is the way to do it, because I think it's a mistake to copy another user's ~/.vimrc especially if you aren't aware of why those settings are in use. You'll learn more, faster, if you start with a blank ~/.vimrc and build it up yourself.
Another tip to advance up the learning curve is to start using vim for everything, not just code. Write email, todo's, documentation, and everything else with it and pretty soon the learning curve doesn't feel so steep anymore.
Another tip to advance up the learning curve is to start using vim for everything, not just code. Write email, todo's, documentation, and everything else with it and pretty soon the learning curve doesn't feel so steep anymore.
The most important thing I would say to anybody that wants to use vim is relax! Here are some steps I think will be helpful:
1 ) Install vim with janus and use gvim/macvim. This will allow you to use vim pretty close to your previous editor.
2) Learn hjkl movement and how to move between insert/movement/visual modes.
3) Try to use them as much as possible. It's ok if you use arrow keys or mouse from time to time.
4) Introduce no more than one additional feature a week.
5) Have fun! There is no "right way" to use vim. Use it how you see fit.
1 ) Install vim with janus and use gvim/macvim. This will allow you to use vim pretty close to your previous editor.
2) Learn hjkl movement and how to move between insert/movement/visual modes.
3) Try to use them as much as possible. It's ok if you use arrow keys or mouse from time to time.
4) Introduce no more than one additional feature a week.
5) Have fun! There is no "right way" to use vim. Use it how you see fit.
I am still on the fence about the usefulness of Janus as someone starting with Vim. Sure it gets you closer to ST, but is that really the end goal? Why not still use ST?
Vim's usefulness comes from the combined effects of many Vim commands, also the benefit of a unique way of doing things. Sadly this combination is hardly available after only a few hours or a day's study. Knowing only a few commands won't give you much reward, and without immediate reward, people often
lose motivation to continue.
IMHO a good approach is to devote one or two months' available time, make yourself super focused, just read, memorize and practice, whenever and wherever you can. Also try not to use Vim for actual work in this stage. Practice a lot with small scripts.
After a month or two of violently focused study/practice, you will either stop for whatever reason (that's OK because the knowledge gained will be useful for the rest of your career), or you have become good at 30 or 40 Vim commands/options/tricks, the combination of them actually make you more productive than before. The reward is sweeeet, so the learning goes on, probably for many more years.
IMHO a good approach is to devote one or two months' available time, make yourself super focused, just read, memorize and practice, whenever and wherever you can. Also try not to use Vim for actual work in this stage. Practice a lot with small scripts.
After a month or two of violently focused study/practice, you will either stop for whatever reason (that's OK because the knowledge gained will be useful for the rest of your career), or you have become good at 30 or 40 Vim commands/options/tricks, the combination of them actually make you more productive than before. The reward is sweeeet, so the learning goes on, probably for many more years.
I went the flashcard route, but used Wunderlist instead. I would look at it at night before bed, and in the morning right after I woke up. Using this technique I felt totally proficient after about a month, with the ability to get work done after about a week.
For me, what finally worked, after many other attempts, was:
1. Run through vimtutor thoroughly [~30 mins].
2. While doing that, memorize the 10-15 commands in the tutorial that stick. Leave the rest (for a later time).
3. Start using vim full-time from now on.
Worked perfect!
1. Run through vimtutor thoroughly [~30 mins].
2. While doing that, memorize the 10-15 commands in the tutorial that stick. Leave the rest (for a later time).
3. Start using vim full-time from now on.
Worked perfect!
What made the difference for me was a Vim version with a project/file drawler, like the one by alloy: https://github.com/alloy/macvim
After a while I got fluent enough with vim to switch to NERDTree.
Btw, such a shame vimR (http://vimr.org/) wasn't around back when I started using vim, it looks awesome to learn vim-motions but still be able sometimes to use insert-mode and mouse if you have to get something done quickly.
After a while I got fluent enough with vim to switch to NERDTree.
Btw, such a shame vimR (http://vimr.org/) wasn't around back when I started using vim, it looks awesome to learn vim-motions but still be able sometimes to use insert-mode and mouse if you have to get something done quickly.
Perhaps this is stating the obvious, but for me, the biggest thing was to not allow myself to fall back on my normal editor. Otherwise, the path of least resistance is easiest to follow.
[Two steps, eh?](http://knowyourmeme.com/photos/572078-how-to-draw-an-owl)
I used vim for a long time on servers, and only there to make quick edits and wasn't very good at it.
I bought a new laptop recently and just didn't install any text editors. I had a deadline a month away and a project where I was familiar with the existing technologies.
That motivated me enough.
Add a bit of vimgolf and a lot of googling and here I am using vim for everything, everywhere. I occasionally catch myself writing emails in vim and then just copying them into Mail before I fire them off.
I bought a new laptop recently and just didn't install any text editors. I had a deadline a month away and a project where I was familiar with the existing technologies.
That motivated me enough.
Add a bit of vimgolf and a lot of googling and here I am using vim for everything, everywhere. I occasionally catch myself writing emails in vim and then just copying them into Mail before I fire them off.
I found Anki / spaced repetition helpful when learning (still learning, always learning) Emacs. I make cloze deletion cards for the commands and their explanations.
Agreed. Especially for the more advanced or less commonly used vim/ed shortcuts, adding them to my general Anki deck was invaluable. I went through "Practical Vim" by Drew Neil and added all the useful shortcuts to the deck, and whenever they would come up for review I would also try my best to put them to use that same day. The card format would be question/answer e.g. "how do you split a window vertically?"
I also used this approach to familiarize myself with the various unix tools I don't necessarily use daily (sed, awk, etc)
I also used this approach to familiarize myself with the various unix tools I don't necessarily use daily (sed, awk, etc)
Still relevant: https://news.ycombinator.com/item?id=2911930
Vim is a huge editor but I don't think the subset of commands that are absolutely necessary to do any editing at all is difficult to memorise; from memory, these are the ones I started with:
hjkl i Esc or ^[ :w :q :q! :wq
hjkl i Esc or ^[ :w :q :q! :wq
Also, if you want to learn hjkl you just have to play some NetHack ;)
But that was what Ornstein meant by cheatsheet. Anyways, why did you "want to learn Vim for a long time", did you feel limited by st?
Right, I thought I heard him mention it, but couldn't remember where. Looks like he mentions it in this post >> http://robots.thoughtbot.com/the-vim-learning-curve-is-a-myt... And really, I wanted to learn so I could pair with other programmers remotely. I had heard that many were using tmux and Vim so I thought it was time.
I don't remember where exactly either, but I think in multiple videos/talks of his, one of his top tips if you're new, is to make a list of your top 5 or so new commands you'd like to learn/focus on each week and keep using or referring back to them so that it starts becoming muscle memory.
And fair enough, was just curious why you kept persisting. :p
And fair enough, was just curious why you kept persisting. :p
Vim is much more efficient. For example, within Tmux, one never needs to leave the terminal; with ST, there's a frequent switching cost which compounds over the course of a day. If one were to put Tim Pope up against an ST master, it's almost certain Pope would win.
I love the iTerm2 + tmux + vim + zsh environment. It takes a little time to figure out how to juggle the configuration for them, but once you do, it's super efficient.
Are you dotfiles openly available? I have the same set of tools, but still find things are slightly off... would love to compare notes.
I'm using the same setup (plus spf13.vim, powerline and Oh My Zsh). It looks beautiful and works very well. Here is a screenshot of my setup: http://postimg.org/image/9jqokq0ll/full/
Well I guess it depends on what you do. That might be true if you use only console based (tui/cli) programs to do your work, but in your workflow, is there any non-console program you use? I'm not trying to make some sort of opposite point here, tmux is awesome, but I'm just actually curious, assuming your work is in programming of some sort (since this is hn), do you use a 'graphical' program in your workflow?
I'm not a programmer but do like hobby programming stuff, and so when I do, I usually have to use a browser to look up documentation of things, possibly even look up bug report threads and sometimes various other things. The browser I believe has to be graphical (while terminal browsers can be very useful, I don't think it's very practical for the majority of your web browsing tasks to be handled solely in a tui browser these days), and so if you do use a graphical browser in your workflow, i.e. when you are working (not playing/procrastinating), that would mean you would have to leave the terminal.
It could very well be that you do not need to leave the terminal since you're already familiar with your language/framework whatever so you don't need to look up documentation like I do (coz I'm hobbying). But regardless, my next question would be when you say "with ST, there's a frequent switching cost which compounds over the course of a day". But wouldn't that be the same with switching between the tmux pane/window/tab with vim in it to the one with a terminal open? Or do you just ctrl-z and fg back and forth in vim? But then ctrl-z + fg is still a form of switching, just different to tmux pane switching.
Perhaps you meant that one never has to move their hands away from the keyboard to go to the mouse (like you would in st), as opposed to leaving the command line of the terminal/tmux (as you would with both vim and st)? And the point would be something like, needing to move hands repeatedly to and from the mouse and keyboard not only pays a toll on speed (of text editing), but also not ergonomically comfortable... etc? If that's the case, yeah I agree.
But you might say that leaving the terminal means switching to a graphical program which means needing to use the mouse... etc. You would be right, except my point is that, that might not necessarily be the case and hence it's 'more correct' to say leave the keyboard than just leave the terminal. For example, in my workflow (for hobbyist programming that is), I sometimes need to use the graphical program, firefox, yet I do not need to leave the keyboard due to pentadactyl. Even outside that workflow, I do not need to leave the keyboard in varous other graphical programs such as video player, image viewer and pdf viewer. You might say that to run a graphical program, the very act of switching windows requires the mouse because you'd typically have to use a mouse based graphical window manager program of some sort so that you could even lay out/draw and switch between the boxes/widnows in which graphical programs exist within. But as long as the platform supports it, the window manager could be configured to have keyboard shortcuts to handle anything the mouse can achieve, or maybe you could even replace the default moused based window manager with a keyboard based one.
Anyways, my question to OP was coming more from his point of view, if he's already comfortably using st, why consider switching to vim, especially after multiple failed attempts? Perhaps he wasn't actually completely comfortable with st and was seeking for something else to solve that, or maybe he heard or saw something about vim that attracted him? As a vim user myself, I already knew that vim is more efficient than any other editor ever, but I'm still always curious to learn about what attracts new users to it these days when all the hype seems to be about newer or more 'contemporary' editors like atom and st, especially if I find something new that I didn't already know about vim. And so I asked him as he didn't state why specifically in the article. (And the article itself didn't mention anything about why vim was special to him either, so I couldn' really infer.)
I asked about st specifically though because I don't know much about it, and so the more I can learn about it, the more I can hopefully confirm to myself that vim is indeed objectively faster/better than st, and hence more peacefully sleep at night. To the reading non-vim user, when I say "faster/better than", I mean a really good vim user versus an equally really good st user. If you don't enjoy using vim, or just do not 'click' in vim's general way of operating, obviously you will be slower and worse in vim than with your editor.
I'm not a programmer but do like hobby programming stuff, and so when I do, I usually have to use a browser to look up documentation of things, possibly even look up bug report threads and sometimes various other things. The browser I believe has to be graphical (while terminal browsers can be very useful, I don't think it's very practical for the majority of your web browsing tasks to be handled solely in a tui browser these days), and so if you do use a graphical browser in your workflow, i.e. when you are working (not playing/procrastinating), that would mean you would have to leave the terminal.
It could very well be that you do not need to leave the terminal since you're already familiar with your language/framework whatever so you don't need to look up documentation like I do (coz I'm hobbying). But regardless, my next question would be when you say "with ST, there's a frequent switching cost which compounds over the course of a day". But wouldn't that be the same with switching between the tmux pane/window/tab with vim in it to the one with a terminal open? Or do you just ctrl-z and fg back and forth in vim? But then ctrl-z + fg is still a form of switching, just different to tmux pane switching.
Perhaps you meant that one never has to move their hands away from the keyboard to go to the mouse (like you would in st), as opposed to leaving the command line of the terminal/tmux (as you would with both vim and st)? And the point would be something like, needing to move hands repeatedly to and from the mouse and keyboard not only pays a toll on speed (of text editing), but also not ergonomically comfortable... etc? If that's the case, yeah I agree.
But you might say that leaving the terminal means switching to a graphical program which means needing to use the mouse... etc. You would be right, except my point is that, that might not necessarily be the case and hence it's 'more correct' to say leave the keyboard than just leave the terminal. For example, in my workflow (for hobbyist programming that is), I sometimes need to use the graphical program, firefox, yet I do not need to leave the keyboard due to pentadactyl. Even outside that workflow, I do not need to leave the keyboard in varous other graphical programs such as video player, image viewer and pdf viewer. You might say that to run a graphical program, the very act of switching windows requires the mouse because you'd typically have to use a mouse based graphical window manager program of some sort so that you could even lay out/draw and switch between the boxes/widnows in which graphical programs exist within. But as long as the platform supports it, the window manager could be configured to have keyboard shortcuts to handle anything the mouse can achieve, or maybe you could even replace the default moused based window manager with a keyboard based one.
Anyways, my question to OP was coming more from his point of view, if he's already comfortably using st, why consider switching to vim, especially after multiple failed attempts? Perhaps he wasn't actually completely comfortable with st and was seeking for something else to solve that, or maybe he heard or saw something about vim that attracted him? As a vim user myself, I already knew that vim is more efficient than any other editor ever, but I'm still always curious to learn about what attracts new users to it these days when all the hype seems to be about newer or more 'contemporary' editors like atom and st, especially if I find something new that I didn't already know about vim. And so I asked him as he didn't state why specifically in the article. (And the article itself didn't mention anything about why vim was special to him either, so I couldn' really infer.)
I asked about st specifically though because I don't know much about it, and so the more I can learn about it, the more I can hopefully confirm to myself that vim is indeed objectively faster/better than st, and hence more peacefully sleep at night. To the reading non-vim user, when I say "faster/better than", I mean a really good vim user versus an equally really good st user. If you don't enjoy using vim, or just do not 'click' in vim's general way of operating, obviously you will be slower and worse in vim than with your editor.
I'm only using Vim for server-side config editing.
And then a good full-fledged IDE for any large software development tasks.
And then a good full-fledged IDE for any large software development tasks.
The two aren't completely mutually exclusive. There are Vim emulators for pretty much every popular IDE out there.
That's also how I've been doing it for some time now - best of both worlds!
Sometimes it can get a little flaky though as recently there were some glitches in the IdeaVim plugin and it hurt my productivity badly (I'm so much faster in Vim mode). The issues have fortunately been fixed by now.
I had always been struggling with Vim for bigger projects because I had to waste many good hours over highly individual sets of dotfiles with plugins like Nerdtree and others (integrated debugging, jumping to function definitions etc) I could have been programming instead... IDEs like Xcode and RubyMine are tightly integrated with their domain out of the box so to me there is not much I could rationalize about in terms of using Vim (unfortunately).
I even picked up WebStorm for node/js/html development recently, naturally with the IdeaVim plugin activated at all times :)
Sometimes it can get a little flaky though as recently there were some glitches in the IdeaVim plugin and it hurt my productivity badly (I'm so much faster in Vim mode). The issues have fortunately been fixed by now.
I had always been struggling with Vim for bigger projects because I had to waste many good hours over highly individual sets of dotfiles with plugins like Nerdtree and others (integrated debugging, jumping to function definitions etc) I could have been programming instead... IDEs like Xcode and RubyMine are tightly integrated with their domain out of the box so to me there is not much I could rationalize about in terms of using Vim (unfortunately).
I even picked up WebStorm for node/js/html development recently, naturally with the IdeaVim plugin activated at all times :)
Step one should be to get it out of your head that vim is hard or hard to learn. Sitting with my son, years ago, I got him doing simple editing of files for me proficiently in less than five minutes. Deleting words and lines and selecting whole paragraphs and sections. Copying and pasting.
He was 15. vim is easy.
He was 15. vim is easy.
1) Having to because the environment only supported Vim and was locked down, and my job depended on it.
2) There is no 2
Because if there is no (1) then why would you?!!!
Because if there is no (1) then why would you?!!!
I haven't tried the full (paid) version yet, but the demo was enough to get me moving around text quickly. Now I finally understand why people use this crazy thing. :)
Also, if you really want to fly through text, try out https://github.com/Lokaltog/vim-easymotion