Most advanced guides throw a lot at you at once. Digesting one or few commands at a time works better for me to really make it stick (and that is the goal right?)
I notice it mentions Ctrl-a and Ctrl-x which "increment or decrement any number after the cursor on the same line". I hate these shortcuts because several times I've accidentally pressed them (e.g. on some level thinking I'm in Spacemacs or in readline) and introduced a hard-to-find bug into my code without knowing it.
Having suffered through learning highly configurable software tools independently enough times, I agree completely with "digesting one or few commands" at a time works better for me too.
Spitballing:
We could probably make a general solution for organically producing "learning guide" if power users 1) share their custom configurations and share the frequencies of commands they use.
Start with the general configuration, knowing nothing about the commands the tool offers. The learning guide is just a queue of "here's the most common config edit that you don't have" and "here's the most common command that you don't know about."
We are already share configs with eachother via the dotfiles pattern. We somewhat share command patterns via coding streams. Seems doable.
(In general, making it easier to learn new tech and for devs to share / refresh the learning material for a new tech seem underdeveloped.)
If I could add one thing to the list I would include `cib` as equivilent to `ci(` for changing everything in a set of parentheses (or brackets for the mnemonic's sake). For me at least the `b` is easier to reach than the `(`.
Most advanced guides throw a lot at you at once. Digesting one or few commands at a time works better for me to really make it stick (and that is the goal right?)