Here's the secret to getting good at vim, at least in the beginning (and at least for me).
Step 1: Start using it in your work.
Step 2: Find out something that bothers you. E.g., something you miss from another editor, or some kind of movement that you make a lot and would really love to automate.
Step 2': Very important for Step 2 - you have to really hate doing anything repetitive or annoying. With time you'll get a feel for what is easy to find a solution for.
Step 3: Figure out how to solve that specific problem.
Later on, you may do what other people say and look around for videos of other people using vim, look at plugins, etc. I only started doing that after I got much "better" at vim.
Just a quick example: I was editing a lot of css files, which always have lines like:
.some-rule {
sometext: 234px;
}
And every time, I'd want to change the number (e.g. change 234px to 200px).
If I used the "standard" vim toolset, I could just jump to the number 2, then do "change word", but then I'd have to retype the "px" every single time, and this annoyed me. Now, there are plenty of ways of dealing with this problem, but I knew about something called text objects, and decided to investigate the idea further, and soon found a plugin that makes numbers a text object.
The end result is that I now have mappings to "jump to the first number in the line" and to "change a number", so my flow is much simpler.
This is a small annoyance thing, but let me investigate the whole topic of text objects, creating custom mappings, etc. And, it solved an actual problem I had.
Step 4 (for me) was realizing that all of these plugins to solve small individual problems were just a bunch of cruft. Especially when you use these plugins, mapings, or remappings (I did that a lot) to hide from learning all of the vanilla movements. So, I still use plugins, but I use them to solve things that I cannot myself solve. Or deal with major vim deficiencies that I just don't want to mess with. And focus my attention on grokking 'help' to learn more abscure movements.
Oh, and mappings/macros are awesome in cases were you want solve specific problems in less moves. I use macros to test out my ideas. I sometimes then make them a mapping. That isn't often, but when I do that, it's because they are general and needed enough.
Step 1: Start using it in your work.
Step 2: Find out something that bothers you. E.g., something you miss from another editor, or some kind of movement that you make a lot and would really love to automate.
Step 2': Very important for Step 2 - you have to really hate doing anything repetitive or annoying. With time you'll get a feel for what is easy to find a solution for.
Step 3: Figure out how to solve that specific problem.
Later on, you may do what other people say and look around for videos of other people using vim, look at plugins, etc. I only started doing that after I got much "better" at vim.
Just a quick example: I was editing a lot of css files, which always have lines like:
.some-rule { sometext: 234px; }
And every time, I'd want to change the number (e.g. change 234px to 200px).
If I used the "standard" vim toolset, I could just jump to the number 2, then do "change word", but then I'd have to retype the "px" every single time, and this annoyed me. Now, there are plenty of ways of dealing with this problem, but I knew about something called text objects, and decided to investigate the idea further, and soon found a plugin that makes numbers a text object.
The end result is that I now have mappings to "jump to the first number in the line" and to "change a number", so my flow is much simpler.
This is a small annoyance thing, but let me investigate the whole topic of text objects, creating custom mappings, etc. And, it solved an actual problem I had.