Learning tips

Highly recommended 7-habits by Bram Moolenaar, though using Vim as an example, the suggestions also apply to other editors.

To those who don’t are lazy and don’t want to invest time in learning to use an editor (The 7th suggestions in 7-habits):

Make it a habit: Learning to drive a car takes effort. Is that a reason to keep driving your bicycle? No, you realize you need to invest time to learn a skill. Text editing isn’t different. You need to learn new commands and turn them into a habit.

Use your muscle to remember, using your brain is easy to forget and slow to actually use the command.

Here’s an 1 hour talk by Bram Moolenaar about the 7-habits.

Grokking vi

This answer “Your problem with Vim is that you don’t grok vi” on StackOverflow is really great (though the question is terrible). Explains why vi is design this way (contains historic reasons)，helps you understand the power of vi. Highly recommended, even if you are experienced vi/Vim users.

The “Zen” of vi is that you’re speaking a language.

Making analogy to language grammar to explain the vi command:

• yw: y here is the verb, w is a movement and which specifies the subject of the verb
• Marks and registers.
  • 4 is enough (the author has 15 years vi experience)
  • registers are also the objects, e.g. "ayw copies the current word into the “a” register
  • If we don’t specify the object, we are actually using the anonymous register
• We can consider the numeric prefix as the adverb of a command
• { move to the begin of a paragraph, } to the end
• Searches are also movements in vi, can be used with verbs

The whole : set of commands was historically inherited by vi’s previous incarnations as the ed (line editor) and later the ex (extended line editor) utilities. In fact vi is so named because it’s the visual interface to ex.

: commands normally operate over lines of text. ed and ex were written in an era when terminal screens were uncommon and many terminals were “teletype” (TTY) devices. So it was common to work from printed copies of the text, using commands through an extremely terse interface.

• Specifying line range
  • :5,10 s/foo/bar
  • :.,$ s/foo/bar . for the 1st line, $ for the last, :% is synonymous with :1,$
  • Use + and - to refer to offset after or before the current line
• :…g means global apply to all lines the match a patter
  • :.,+21g/foo/d means “delete any lines containing the string “foo” from the current one through the next 21 lines”
• :...v means apply to the lines that DON’T match

It’s interesting that the common Unix command grep was actually inspired by this ex command (and is named after the way in which it was documented). The ex command :g/re/p (grep) was the way they documented how to “globally” “print” lines containing a “regular expression” (re).

Couple of other ex commands which are worth remembering:

• d for deletion
• m for moving lines around
  • :% g/foo/m$ … and all the “foo” lines will have been moved to the end of the file
• j for joining lines
  • :% g/^ /-1j for every matching line, go up one line and join them
• :% g/foo/s/bar/zzz/g for every line containing “foo” substitute all “bar” with “zzz. Consider how to do this using only s command and you will appreciate this command.
• r read in content.
  • r! is really powerful, which reads in the result of a command

• so can be used to execute a series of commands in a file.

  • The + option can be used to specify any valid ex command/expression, e.g.

    vim +'so mymacro.vim' file
    

• The @ command executes the contents in a register as if it were a vi or ex command.

Change case with regular expression

This kind of unexpected ability really makes me love Vim. From wikia

It’s as simple as placing \U or \L in front of back references which you want to change the case of, and \E at the end. Vim will make the text in the backreference uppercase or lowercase (respectively). Use \u and \l (without the \E at the end) to just change the case of the very first character in the backreference.

(A “backreference” is a part of a regular expression that refers to a previous part of a regular expression. The most common backrefernces are &, \1, \2, \3, … , \9).

Example: to change %XX to lower case %xx:

:%s,%\(\d\|[ABCDEF]\)\{2},\L&,g

I don’t know if general purpose language’s default regular expression library has this ability.

Permuted index to help the command easier

From Vim Permuted Index.

Even for experienced Vim user, it’s still difficult to find the help for a command if he does not know the command name. This article creates a permuted index like Vim help file from the Vim help files. So it’s possible to search command from this file.

Runtime directories and files

Read the Runtime directories and files section of Vim for Rails developers: Lazy modern configuration to learn how to organize your configurations. The following contents are almost exactly copied from that section.

• after

  You can use it to override system settings, it has the same structure of the entire vim configuration directory (itself excluded).

• autoload

  You can put in this directory all the functions you want to call with a particular mapping or functions without problems. The nice thing is that these functions will be only loaded the first time you call them.

• compiler

  The files you put here won’t be loaded by Vim at startup but you can use them with the compiler command in order to set the `errorformat“ and the make options.

• ftplugin

  The files in this dir follow the simple convention based on the filetype of the buffer you are opening with Vim. So if you put here a file called `ruby.vim“, it will be loaded only when you open a Ruby file.

• ftdetect

  This directory follows the same convention of `ftplugin“ but serves a different purpose. You can use this dir to detect filetypes when a particular condition is met. See docs for a good example.

• plugin

  All the files that you put here will be automatically loaded by Vim when you open it.

Now you have some information to clean your vim directory and you can focus on cleaning and removing stuff.

• Divide your mapping in two types

  • General mappings Mappings you will use in all files.
  • Filetype mappings Mappings you will use, for example, only with Ruby files or with Coffeescript files.

• Organize your general mappings

  I’ve used a dir with some files in it, each file groups a number of mappings according to its own name. It will help you to focus on what you really need and what you currently have.

  Put your filetype based files in the after/ftplugin directory and use the buffer argument for mappings, it’s an important feature and you should spend some time to understand it. Maybe a bit poorly known. Thus, you won’t mess Vim configuration for those files.

• Order personal settings and group your plugin settings in your vimrc

  Use the criteria you find more logic for your setting. But keep them ordered. When you change something, you’ll know where to go. Grouping your settings by plugin is a good idea too.

• Comment your settings

  I’m writing about it because I would force myself to do it too. It’s important even for obvious things. If you have your vim directory on a public service like github or bitbucket, you’re being kind to other people.

I found that I like the comment style in The Vim Configuration of Champions. And with proper comment and organization, putting all configuration in a single .vimrc is also not a bad idea.

Misc

• Scroll 2 files simultaneously. Execute :set scrollbind on all the buffers.

Other Recommended reading

• How I boosted my Vim
• Coming Home to Vim
• The Vim Configuration of Champions