The title is loosely based on the book by Stephen Covey. The actual presentation was over in about 40 minutes and then it was time for questions - also about 40 minutes. The talk started a bit slow, but after making a few Vim versus Emacs jokes the pace increased.
First the speaker listed the 3 steps one has to follow to make every habit work.
- detect inefficiency
- find quicker way
- make it a habit
After that the slides were about the 7 vim habits. Obviously, there was too much information for a blog, but there were a few gems, I feel obliged to share.
Habit 1 Moving around quickly
First of all use the h, j, k and l keys - not the cursor keys. If you can touch type this makes much more sense, because these keys are on the home row and are therefore easy to reach. Many people in IT cannot type, which is surprising knowing that this is an essential part of the day to day work. Luckily, it is very easy to learn. All you need is a simple computer program and thirty minutes a day for a few weeks.
As a programmer I need to change code very often. For instance, to change the name of a function or variable. Basically, what was described in the video was a kind of Mark Occurrences feature as available in Eclipse.
:set hlsearch highlights whatever you are looking for. Preferably you should have this in your .vimrc file. You can then use * to find occurrences. This is also a vim tip - I think also referred to as the “super star” operator. :nohlsearch removes the highlighting. In Eclipse you have an on/off button for Mark Occurrences. Personally I find the vim way a bit confusing. I don’t know if other people feel the same way, if so maybe we should do an enhancement request . The last step is to set the incsearch option.
I am not a big fan of marks, however I found a vim plugin that visualizes marks in a very convenient way. ShowMarks is a vim plugin that places a sign in the leftmost column of the buffer. The sign indicates the label of the mark and its location. This means that you do not need to remember where your marks were and as a bonus the default marks made by vim are also visualized. By default the following key mappings are defined:
- \mt : Toggles ShowMarks on and off.
- \mh : Hides an individual mark.
- \ma : Hides all marks in the current buffer.
- \mm : Places the next available mark.
The plugin is installed by simply unzipping showmarks.zip into the $HOME/.vim or $HOME/vimfiles folder. Signs support has to be enabled, otherwise you get a warning when you start vim. ShowMarks worked with MacVim immediately, however not on the command line with Terminal. I found out that you need to compile vim with the (big or huge) switch. If you have MacPorts installed, you can execute
sudo port install vim +huge +python
port info vim
gives the following variants
Variants: athena, big, cscope, gtk1, gtk2, huge, motif, nls, perl, puredarwin, python, ruby, small, tcl, tiny, universal, xim
Tiny means that most features are disabled, then in increasing order of features enabled you have small, big and huge. Probably huge also includes python support. The MacPorts vim variant that I have now does not give a warning or error anymore, however instead of a mark I see a blue square.
The xterm terminal that comes with the Mac X11 application does not have this problem. Unfortunately I have been using the Terminal application more often for aesthetic reasons.
Habit 2 Don’t type it twice
Typing the same thing over and over again costs energy, time and is of course boring. My favorite command, the dot command, makes life a lot easier. Ctrl N or Ctrl P does insert mode completion, so you can type a few characters and then let vim complete the word. This is especially useful when you need to write a long and hard to remember method name.
This might seem obvious, but you can avoid a lot of typing by copy pasting or cut and paste. The good thing about vim is that you can do this really efficiently without using a mouse. You can, for instance, select a block in visual mode and paste it somewhere else or delete a line with dd and put it where you need it.
Sometimes you need to repeat a certain sequence of commands. In such cases you can record a macro. The usage is very similar to marks. qa records a macro, which then can be executed with @a. Unfortunately, it is quite hard to get this right. I tend to keep my macros short and simple. Still it seems that there are not many opportunities to record macros.
Habit 3 Fix it when it’s wrong
Stephen Covey’s third principle is called “Put first things first“. With a bit of imagination you can equate it to “Fix it when it’s wrong”. So put fixing errors first. In the talk this was mainly about spelling and the spelling checker in vim. The advice was to create a list of spelling mistakes and make vim automatically correct them.
:abbr teh the
was the example given in the talk. My most common mistake is writing “taht” instead of “that”. At least that is what I catch myself typing in Skype frequently. Skype as far as I know does not have any vi key bindings or tabs for that matter. Another enhancement request is emerging .
I find the spellchecker in vim quite useful. :help spell displays the relevant help page. ]s shows the next error, [s the previous one and zg adds the word to the dictionary. z= gives suggestions from the dictionary - to get out of the suggestions list type Ctrl C.
Habit 4 A file seldom comes alone
An analogy with Covey’s fourth “Win/Win” principle is completely missing here. Also I am not too keen on the whole “Win/Win” concept. Maybe I feel that way because as a chess player I translate “Win/Win” to a draw. A draw is no good usually, unless you are in a tournament situation, where you are ahead in points.
As a developer you tend to work on projects, that is why IDE’s as Eclipse are so project minded. Projects consist of multiple file, such as source code files, configuration files, all kinds of resource files, documentation etcetera etcetera. Vim does not have the notion of project as far as I know, but still lets you work on a group of related files easily. In a previous post I already mentioned using tags files and the TagList plugin.
In the talk Agide is mentioned. This is an old project also from the creator of vim promising to bring us an IDE based on vim. You can create projects or debug your code with gdb. Most operations are performed by mouse just as in conventional IDE’s. Personally I don’t like Agide’s GUI - it is ugly. Projects can be build from Agide, but you still have to save your program before building. Not as convenient as Eclipse.
Habit 5 Let’s work together
About the communication between vim and other applications like for instance Word. The trick for copying to and from Word is to have
:set tw=0 wrap linebreak
- You run a headless instance of Eclipse which all vim instances can then connect to.
- You run the Eclim server inside of the Eclipse GUI and then interact with it via external vim instances.
- The same as the second scenario, but here gvim is used as embedded eclipse editor.
At first I was only aware of the first scenario, which seemed a bit limited, but now I will definitely give Eclim a shot. I am just wondering, whether I can use MacVim as well. Also I am not so clear on the Eclipse and vim plugins situation.
Older version of MS visual studio supported vim and I know at least one commercial plugin, that seems to do the job with the latest version of Visual Studio. According to Bram Moolenaar - Mutt and Sniff support vim out of the box.
Habit 6 Text is structured
I find this a bold statement. Text does not need to be structured although it usually is. The structured text that this habit refers to will have some kind of structure that can be used to our advantage. In programming there is the edit, compile, test cycle. Not necessarily test driven. When I was in university we did not have fancy IDE’s as Eclipse. We would run commands like gcc from the command line. You would then get error messages in the console with line numbers, which were not always correct by the way. Later I worked with MS Visual Studio, I did not find it very user friendly, however. The point is that it was very cumbersome to have to remember the line number where something was wrong and then go back to the source file for editing. In the vim world, a program can be compiled with :make. :clist lists compile errors and :cnext and :cprevious move through the errors.
There are thousands of vim plugins available that can deal with all kinds of files. In order to handle a new type of file, one can write a small program in several scripting languages, including a small language created specifically for vim. I read lately a bit about the vim scripting language. It appears, that this language at least on the surface looks like Python. There are some object oriented features and exception handling. If you get ambitious, you could even write your own libraries.
I made a small plugin for myself to help me blogging. It gives me the ability to find a suitable link, for something, that I am writing about. All I have to do is select a phrase I want to search for and yank it into the unnamed register. You can check the contents of the registers using :registers. Then I will call my special script with:
This will magically insert the first relevant link that the Google AJAX service can find. Here is the code, use at your own risk:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
function! GoogleLink() python << EOF import vim, urllib query = vim.eval("@\"") url = "http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=" + urllib.quote_plus(query) handle = urllib.urlopen(url) searchResult = handle.read() commaSeparatedList = searchResult.split(',') link = '' for i in commaSeparatedList: if i.startswith('"url"'): i = i.replace('"url":', '') link = i.replace('"', '') break vim.current.line = vim.current.line.replace(query, '<a href="' + link + '">' + query + '</a>') EOF endfunction
As you can see the plugin is still in the prototype stage. It seems to work, but I haven’t tested it thoroughly and the feature set is limited.The AJAX service produces JSON for the search results. A snippet of the TCP stream dump:
The Python JSON module was introduced in Python 2.6. However, MacVim 7.2 is compiled with Python 2.3 for backwards compatibility with Tiger. It is possible to recompile MacVim with higher version Python support, but it is a bit of a hassle. Luckily, I didn’t really need full blown JSON capability. Instead I just did some simple string manipulation.
Habit 7 Sharpen the saw
The presenter explained, how to slowly, but surely get better at using vim, by continually finding improvements and making them a habit. You need to take the time, do it step by step - repetition is key. Repeat after me . Sharpening the saw can be done by searching the documentation using :h or :helpgrep, subscribing to mailing lists and RSS feeds or searching newsgroups. Here is a list of vim related feeds I have been reading recently:
The vim user manual can be found at the Vimdoc website. From the video I learned that the user manual was originally based on the book “Vi IMproved - Vim” by Steve Oualline. This book described the features in vim 5.7. The user manual has been updated for the most recent vim version. In fact, I read Steve Oualline’s book and recently also the vim user manual and to me they seem completely different documents. In my opinion, they are complementary and you can read them both. The book has a larger number of pages and has diagrams. The user manual is on the other hand, as I said, up to date and written by Bram Moolenaar himself, as far as I can tell. Another interesting resource is the wiki book “Byte of vim”. It has many useful links and information on plugins.
Google can find several vim cheat sheets. At work I have set the vim graphical cheat sheet as my wallpaper.
The neat thing is that the keyboard image has its keys mapped to vim commands. This, combined with the pretty colors, makes it visually appealing and also a great touch typing learning aid. As an added bonus, I also have something to talk about when somebody is staring at my desktop. I remember somebody saying that there is also a graphical Emacs cheat sheet. I think that was a joke, because you cannot possibly visualise Emacs key bindings in this way.
At this point, I have written more than the equivalent of a hundred tweets. This is more characters than in my first attempt. So this writeup was based on a video, which in turn was based on a book. In any case I got the opportunity to structure my text better and apply the principle of chunking ( not one of the seven habits ). It turns out that I don’t have enough material for a vim article series trilogy currently. Next time I will keep it simple and blog about my Google App Engine experiments - a deadly mix of Python and Flex. Ladies and gentlemen, I hereby declare the comments section open!