My issue with getting better at vim is that I've gotten to the point where I'm comfortable moving around text, copying/pasting, and everything I would normally do with a mouse. I know vim is so much more than that, but it's one of those things where "you don't know what you don't know" and because of that, I don't have the incentive to continue learning. Hopefully this post will inspire me to incrementally advance my vim usage.
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.
Capital letters and numbers are global, lowercase is buffer local. There are also dynamic marks that vim sets which you can use instead of manually navigating or setting marks. For example, g'. will go to the position of the last change. You can use :help marks to get a lot more info.
Slightly tangential, I also found "Your problem with Vim is that you don't grok Vi" a good source of things to learn from. While it starts off sounding like a rant, it isn't - I think it actually manages to convey a fair bit of the philosophy :)
Opening a new buffer. Figured I'd try :new, and wound up getting good at splits. Still don't know how to just open up a new, blank buffer in the window I'm in without specifying a filename to :e.
I use them all the time (I've switched them on by default in .vimrc) while editing C++ code. Extremely, extremely helpful to get the structure of a file at a glance. For example, if a 400-line file has about 10 functions in it, you can fold all "zM" and instantly you see only the function signatures, while the bodies are folded.
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.
I use folds for one specific thing: I have a general "notes" file for home and for work, which is a big outline where I put anything I'm thinking about or working on. I usually don't delete stuff, so the file grows over time. I make a fold for each top-level item (~project or subproject) and sometimes nested folds if things get too big. I always use fdm=marker. The automatic fold methods are too confusing.
Everyone uses tag files, in some sense, when they use :help :)
I don't use folds that often, but when I do they are be extremely helpful. When you run across that block of code that's way longer than it should be, and need to collapse it so you can see the context around it, folds can be very useful. Also for taking care of long comment blocks.
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.
I couldn't live without folds. Whether I'm in C++, Java, Go, Ruby, or a custom ASCII report I've written, I use them extensively. I add fold tags around every method/function implementation, and sometimes an additional one around around groups of them (e.g., classes). I generally set foldlevel to 0, so most files I enter have a few intro lines and then N folds, so that even large (1000+ lines) source files fit into a single page or two. I almost never use searches or tags to find declarations, since I can usually navigate to them directly with a single keystroke.
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.
I use them for learning a library or framework. I'll fold all of the functions, methods, etc. in a file and and then unfold to dig deeper. I work on a 13" mba so it helps with the lack of vertical screenspace.
I still don't fully understand how folds work (e.g., how can I get them in my JavaScript files by default?), and thus I find them difficult to work with, but when I can get them to work, I'm very glad of them. They make navigating round a large file much easier.
I use them. They don't help as much with new development, but when editing a large pre-existing code base it makes perusing the contents of a file much easier. It's like getting a table of contents for free if your code is cleanly organized.
Being able to move about is the first step. The second is to see that you can combine actions with motions. There are many more, of course - but IMHO, crossing these two steps takes you past the tipping point.
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.
advice: put just a bit more boring memorization type time into honing your discovery ability; ie hit the :h a bit, find some tutorials you like, pick up the "practical vim" book, print out a vim cheat sheet. not too much; just enough so you have somewhere to go when you have a question.
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.
The thing I've found to be really effective at learning "what you don't know"is pairing with other more experienced vim users. You'll see some wizardry occur and you can ask them how they did it. I consider myself an experienced vim user and I still learn new tricks when pairing with other people. Obviously not everyone knows vim users to pair with, but you may be able to find people at meetups.
"My issue with getting better at vim is that I've gotten to the point where I'm comfortable moving around text, copying/pasting, and everything I would normally do with a mouse."
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.
