Vim Recipes(vim.runpaint.org)
vim.runpaint.org
Vim Recipes
http://vim.runpaint.org/
16 comments
Thanks for the feedback. :-)
: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. ;-)
: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.
I've found A Byte of VIM to be quite useful, though: http://www.swaroopch.com/notes/Vim
I've found A Byte of VIM to be quite useful, though: http://www.swaroopch.com/notes/Vim
Something I recently learned that is really cool:
:<area>!<command>
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.
:<area>!<command>
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.
Verbose and not worth the read IMHO. The best tip in this entire document was changing a sentence to title case.
>Select the text you want to convert, hit :, then enter the regex:
>Select the text you want to convert, hit :, then enter the regex:
s/\<\(\w\)\(\w*\)\>/\u\1\L\2/g.
nnoremap <A-c> :s/\<\(\w\)\(\w*\)\>/\u\1\L\2/g<CR>
vnoremap <A-c> :s/\%V\(\w\)\(\w*\)\%V/\u\1\L\2/g<CR>
Thanks for the suggestion. I'll incorporate it into the recipe.
I've posted this before, but i found the best way to learn some vim is by example. you soon get the idea.
http://rayninfo.co.uk/vimtips.html
I've found it quite an efficient editor with MacVim+Ruby and Jamis Buck's FuzzyFinder TextMate.
http://rayninfo.co.uk/vimtips.html
I've found it quite an efficient editor with MacVim+Ruby and Jamis Buck's FuzzyFinder TextMate.
I'll concede it is verbose, but having a task oriented guide is much more useful in certain cases than the standard :help.
I was happy to see a nice visual explanation of undo branches. Something that I've known exists but never learned to use well.
I was happy to see a nice visual explanation of undo branches. Something that I've known exists but never learned to use well.
Wow, looks solid. I've only been viming for a year, so no doubt theres plenty of knowledge gems for me here.
This is vapid. For instance: http://vim.runpaint.org/extending/creating-keyboard-shortcut...
No mention of inoremap, nnoremap, etc.
If you want to learn Vim well, do the following:
1. Ask "stupid" questions on #vim on freenode. Learn to use :help
2. Use :help
3. Ask the vim-use group any questions not obviously answered by :help
No mention of inoremap, nnoremap, etc.
If you want to learn Vim well, do the following:
1. Ask "stupid" questions on #vim on freenode. Learn to use :help
2. Use :help
3. Ask the vim-use group any questions not obviously answered by :help
4. Be able to sprint through vimtutor. You have to learn to walk before you can run.
5. Never, ever use gvim. Forget about the mouse.
5. Never, ever use gvim. Forget about the mouse.
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).
Point taken re: console support. I was thinking about the menu bars, too. Many users probably have them turned off, though.
Yeah, nothing's wrong with gvim after you throw 'set guioptions-=bmrt' and a colorscheme line into your .vimrc.
Evim--now there's a crime.
Evim--now there's a crime.
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. :-)
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.