How very verbose. Isn't vim designed as a terse, efficient, no-nonsense text editor?
http://vim.runpaint.org/basics/saving-a-file/ for example, gives me several screens full of jabber, broken into Problem, Solution, and Discussion, plus the ubiquitous Needless Comment Form as on every page. All this fluff, and :w is mentioned only in a user-added comment.
I don't mean to say you can't learn anything from this document, just that you could do a lot better with ':help tutorial' and maybe a googled cheatsheet. The tutorial really only takes half an hour, just like it promises.
:w is mentioned as a footnote because :up is more sensible in the general case, as it preserves file timestamps and saves needless disk access, the latter being particularly useful when dealing with larger buffers or working over a slow link. If somebody wants a quick answer to the question, they can just look at the Solution. If they want to understand how saving works, and its how it relates to existing mental models they have of text editors, the Discussion elaborates.
This is in contrast to the "cheatsheet" approach, which does exactly what you suggest. It gives a single cryptic command, then moves on to the next example. This may be sufficient for you and I, but newer users would prefer a more cohesive explanation.
Oh, and the "Needless Comment Form" was added after multiple readers requested it. Apparently people find it easier than cloning the Git repository and submitting a patch. ;-)
Agree, it is too verbose. If I am using vim, I won't be looking for cookbook entry explaining simple tasks. There is probably be audience who'd benefit from the book, but does not appeal to me.
will export the <area> to <comand> and then replace <area> with the output of the <command>. So you can do:
:%!sort # Sort the entire file.
:.!awk '{ print $1 }' # Replace the current line with the
first word/column.
So much power with this really simple set of commands. You can also highlight the an area using visual mode, and then just type ':!<command>' and it will autofill in the area for you.
What does gvim have to do with the mouse? Regular console vim supports the mouse, and there are perfectly good reasons to use gvim without it (e.g., better color support, "Edit with Vim" in Windows).
I've tried to hit the right balance between being thorough and readable. There are at least ten ways of connecting mappings with modes, and double that if you care about recursive definitions. That's fine for a reference manual, such as :help, but the detail can seem daunting to the amateur user.
It's more than likely that I haven't achieved this balance in places, and if so I welcome help to clarify them.
Lastly, as I wrote on the index page of the site, this is still a draft. I published it so I could get feedback. :-)
I think you're missing the stated point of the book -- to focus on tasks not commands. The :help system can be a bit overwhelming to someone new to vim, especially if they are not sure what to search for help on. People learn in different ways, one of which is task oriented instead of memorizing commands from a manpage.
I don't mean to say you can't learn anything from this document, just that you could do a lot better with ':help tutorial' and maybe a googled cheatsheet. The tutorial really only takes half an hour, just like it promises.