Different views of what are basic and advanced Vim features
Although vim is now my most regularly used editor (and it really is vim, not vi), I still have lots to learn about it. Thus, every so often I wind up reading guides to Vim, which often label themselves as being for 'beginning users' or 'intermediate users' or 'advanced users'. One of the interesting things in reading these guides is hitting features labeled as basic that I don't know, or features labeled as advanced that I consider perfectly routine.
(My most recent reading is this one, which I haven't even finished yet.)
For some features that are sometimes considered advanced, like address
ranges, I think a lot of this has to do with the path I took through
various editors on the way to today. For instance, I've seriously
used a version of Unix ed, and it's hard to use ed without getting a
fairly thorough exposure to address ranges. This was reinforced by
both sysadmin use of
sed and my long running fondness for the sam
editor. Use of
ed and then
sam left me completely
comfortable with the idea of doing editor operations as (Ex) commands.
(I don't know if marks are generally considered an advanced concept, but
as a sysadmin who uses
less a lot and jumps around in various sorts
of files to find things, marks are very familiar to me and I use them
all the time. Sam has the idea of a mark but only a single one, which is
easier to keep track of, and it's been so long since I seriously used ed
that I can't remember if I really used marks in it.)
When I run into basic vim features that I don't know or haven't mastered, I generally remind myself that I basically drifted into vim instead of actively learning it (including vi). I did at one point long ago read through what was then the vi tutorial, but I did it in another editor (which didn't help get it to stick). This path into vim has left me learning things on a scattershot basis as I stumble over them and decide that they're worth it (not every vim feature is for me).
Part of this is that I use vim primarily as a sysadmin, which is to say that I'm either editing text (such as email) or I'm working with generally small amounts of code, or at least of editing code. My editing sessions tend to be short; I'm definitely not spending all day editing code. If I was, I would probably be more driven to learning vim features that improved that. Plus, right now and likely for the indefinite future, my editor for serious coding is still GNU Emacs for various reasons.
(The pattern of vim things that catches my interest is quite driven by sysadmin interests, from windows while modifying related files at once through mass commenting out references to a machine to changing a bunch of files in the same way at once.)