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.
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.
* find/replace/regexes
* registers and macros
* vim settings (spell, list, highlight, number, wrap)
* the plugin ecosystem
* editing multiple files simultaneously (splits, buffers, moving between them)
* folds
Anyone else want to chime in with stuff I've either forgotten or don't know I don't know?
Tag files would be another good one.
So while I agree with you in that they aren't a part of my typical workflow, they are a piece of vim that I'm glad I familiarized myself with.
Everyone uses tag files, in some sense, when they use :help :)
How to enable it: use "set foldmethod=syntax" (with C++) or "set foldmethod=indent" (with JS, where "syntax" doesn't work for me). Also, I use "set foldminlines=0" so that 1-line paragraphs get closed as well (it looks more consistent).
How to use it: close all folds "zM" (I remember it because the M is shaped like it's all folded on itself). Open all folds "zR". Open one fold "zo", close one fold "zc". Open one fold recursively "zO", close one fold recursively "zC".
By the way, I almost never use manual folds, so "zf" is almost useless to me.
FWIW, I map <Space> to za, so that I can unfold/refold quickly. I also map - to zx to quickly fold up a file I may have drilled some holes in.
Vimcasts (http://vimcasts.org/) has some good tutorials. Vimgolf (http://vimgolf.com/) also has some good exercises.
https://github.com/rking/ag.vim https://github.com/kien/ctrlp.vim
Save me so much time opening files and finding matches+open-at-match
HN thread: https://news.ycombinator.com/item?id=2911930
For example - '%' matches parentheses and braces. So if you want to delete a block of code, you could go to the opening (or closing) brace, and do "d%". If you wanted to indent only that block of code, you'd do "=%". In this context, ":help motion.txt" makes for a good read.
Apart from this, I'd also recommend listing down things about your current workflow that you find irritating, and trying to find solutions for them in vim.
For instance - I wanted to be able to browse through cscope matches in a regular vim buffer than the ridiculous less-like interface that's the default. I found quickfix, which solved my problem neatly. I then wanted to open each match in a vertical split, rather than in the same window - I ended up writing a little bit of vimscript and a keybinding for this.
Sometimes, when going through a gazillion cscope matches, I find it convenient to hide stuff that isn't relevant - I use (manual) folds for this purpose.
then, code in vim. at every pain point ask "is there some faster/easier way to do this?" sometimes you'll find something that seems great, then never use it again. other times, you'll relieve a recurring pain point and at the same time incorporate expanded facility with vim. after awhile, you'll pretty naturally start messing with vimscript as well.
in other words, i think videos and tutorials of "look at how powerful vim is in this situation!" can only go so far, at least until you've really expanded your horizons through practical use and need.
edit: the earlier advice in responses to you (some of which i basically just repeated) is good too. mine could be distilled into a sentence: "learn vim by coding in it, but allowing time for 'how could i do this better?'" on the one hand, just do your normal work. on the other hand, don't stay satisfied with being "good enough" at vim to do your normal work. that's where the learning curve is, and after you do that artificial thing (overdoing "can i make this easier?") it quickly becomes natural.
exactly why I use Vim this way. On DEC VT-100 terminals this was the only way you could work and I must say I sometimes cheat and add the necessary bash commands to make it work on my console.