The Joy of Vim, Part One

Here’s the first in a series about how vim (“ vi improved”) is improved.

If you’re an Emacs user, should you read about vim? If you chose Emacs because you thought vi was crippled, or if you’ve never used more than a few of Emacs’s features, an overview of vim might surprise you: vim is both compatible with vi and is much more powerful. For instance, vim is scriptable, has a windowing version and a graphical user interface, as well as a myriad of other features that only Emacs had up until now.

If you’re a vi user, should you read about vim? Of course. You’ll feel comfortable as you learn all of the new features, which are much more than cosmetic.

Why cover vim in the first place? Are we playing favorites or what? (After all, the text editor you use is almost a religious issue among some Linux and Unix users.) Your columnist uses vi, Emacs, ed, nano / pico, and others, but — he admits it — his fingers were trained for vi. In 1981, on an overloaded VAX 750 running BSD, vi started more quickly than Emacs. (Actually, ed was the only really quick-starting editor.) This series of articles will be a look at what’s new in vim from the point of view of a 25-year vi user.

If you’re a vi user on Linux, you may not even have even have realized that you were using vim: just as bash generally stands in for old sh, vim is the default vi on many Linux systems. Unless you invoke it as vim, though, it’ll act basically like vi without a few of the worst bugs.

There are also Microsoft Windows and MS-DOS versions of vim (see the download page, https://www.vim.org/download.php). If you have to use a Windows machine, this is a great way to get a familiar cross-platform editing interface. vim can handle both Windows and Linux end-of-line styles and convert between them, so it’s easy to edit a Linux file on a Windows system or vice-versa.

There’s no way to cover more than a few of the new features in vim: there are just too many.[ For more information about vim version 7, see the feature beginning on page XX.] This month, we’ll cover some overall changes, introduce the help system, look at vim ‘s windows. In the next columns, we’ll look at some of the many new commands and configuration options — not a complete list, just some of the most useful, including scripting, editing the command line, selecting text visually, making macros without writing them, and (as they say in late night informercials) “much, much more.” vim version 7 was released at the end of May, after years of development. We’ll cover it in the last column of this series.

If you’ve never used vi or vim before, you should be able to read this article and get the gist of it, but you probably shouldn’t try the examples. Using a multi-mode editor like vi (where your keys do different things in different modes) can quickly get confusing until you’ve read a basic introduction and used the editor for a while. This article is not a basic introduction to using vim.

What’s Old in vi?

First, it’s important to point out that vim isn’t the only other version of vi. There are many. Some of the vi limitations that alternate versions of vi have tried to work around include:

*Selecting a block of text (for copying, deleting, and so on) is done invisibly. In traditional vi, you have to remember, or visualize, the start and end points of the block.

*No obvious indications of whether you’re in insert (text-input) mode or command mode. Unless your version of vi tells you in the status line, you just have to remember.

*Trying to un-do more than a single change is tedious or impossible.

*Un-doing the results of macros (stored sequences of commands and text) works only partially, not at all, or even adds errors to the previous text.

*Writing macros requires typing Control-V once (or several times) in places you might not remember (or expect).

There are many, many more quirks and limitations. (Experienced vi users know them by heart.)

The best workaround for all of these problems is to save your work often — before any operation that might fail (you learn to anticipate these.), after every significant change, or maybe even after every change. (No, original vi doesn’t keep backup copies of files you’re editing. You have to do that manually, too.)

vim address all of the aforementioned shortcomings. It also has a raft of new features that were shoe-horned (amazingly well) into new commands and options, while still keeping almost complete compatibility with old vi (especially in the vi compatibility mode).

What’s New in vim?

What’s new in vim? A lot. Section 1.4 of the online vim FAQ, available at http://vimdoc.sourceforge.net/htmldoc/vimfaq.html, gives a brief summary —s and that list alone would fill half of this article. Let’s pick a few new features:

*Built-in, searchable. hypertext-like help. This works in context mode with a tags-like interface, just one example of how well vim builds upon original vi features. (With all of these new features to learn, you may need the help for a while.)

*Multiple windows in console mode, as well as a GUI mode. Now you can see more than one editor buffer at a time; you don’t have to pick just one.

*Commands in the ex line (starting with a colon, :) can be recalled and edited. There’s no longer a need to write a macro to edit a single ex command. or to backspace and retype. or to copy and paste an ex command with your mouse, carefully remembering to insert Control-V at the right places.)

*Lots of configuration options to give you much more control over the editor.

Let’s see some examples, using the console (terminal) interface, not the GUI.

The Bottom Line

Start by opening an existing text file, or a new file, with vim:

$ vim somefile

The bottom of the window should look something like this:

"somefile" 120L, 4810C      1,1      Top

This status message indicates that the file has 120 lines and 4,810 characters. The cursor is on line 1, column 1. You’re in the top (first) screenful of the file; if all of the file can be displayed in this screenful, you’d see All instead of Top.

(Instead of 1,1, you may see something like 1,2-9. This happens if the first line of the file is indented with a Tab character. The 2-9 means the cursor is on the second character in the line — because the first character is a Tab — and that this character is displayed in the ninth column on the line because the Tab causes indentation. If you move the cursor to the next character, with l or the Right-Arrow key, the legend changes to something like 1,3-10, which means: line 1, character 3, actual column 10.)

Starting the Help System

If you aren’t reading a book or Web documentation, you’ll probably want to start with the built-in help. So much is new in vim that its extensive help system is worth getting to know! You can navigate the help system with familiar vi-like commands. Opening the help system also splits your terminal into two windows. (Let’s cover windows in the next couple of sections.)

There are several ways to start help:

1.Type :help and press Return to take you to the table of contents.

2.Type :help topic and then Return to view the help for that topic. This may not be too useful unless you know the exact name of a topic.

3.Type :help topic then Control-D to see all the matching topics. As it did here, vim does completion in a lot of cases, similar to bash and other shells. For instance, vim can automatically complete a file name when you open a new file.

Let’s look at windows and help using the second method.

Windows with Help (and Help with Windows)

Type :help window and press Return to get help on the window topic, whatever that happens to be.

Your terminal should split into two equal-sized windows. The file you were editing (if any) is at the bottom and the help text is at the top. In the top window, you should have a listing of the ’window’ option. (As it turns out, in vim help, option names are surrounded by single quotes, which you don’t need to type.) If you scroll up — with Control-U, for instance — you’ll see that the ’window’ option is one of a list of of vi options that vim doesn’t support.

Although the information in this table is worth knowing (you might want to read it now), it’s not what we’re looking for. Type :q and press RETURN; the help window should close, returning you to your original file.

As you’ve seen, while your terminal is split into windows, the commands you type affect the current window. And typing :q doesn’t quit the editor (as it would in vi); it closes the current window. However, if you have only one window open, closing that window also terminates the editor.

More Helpful Help

Let’s try the third help method using auto-completion. Type :help window and press Control-D to show all of the possible completions. Looking through the list (some 40 results in four columns) should give you an idea of just a few of the new features in vim.

At this point, you can edit the command-line (which still says :help window) to fill in the name of the help subject you want. For instance, you could use the arrow keys to move around the command line, delete and insert characters. Instead, press Tab.

Pressing Tab on the command-line cycles through all of the possible completions. The first is :help ‘window’, which we’ve already seen (it describes the window option). Press Tab again for :help windows, which describes windowing overall. Press Return to open this help topic. Again, the terminal splits into two windows.

In the top window, the cursor should be on the word *windows* in the string *windows**buffers*. These are the two names for this particular help topic. (So, at this point, if you type :help buffers and press Return, the same help topic should appear, but the cursor should land on the topic name *buffers*.)

The vim help is organized into a series of separate files. Use the standard vi command Control-G to get info on the file in the current window; it’s something like /usr/share/vim/vim63/doc/windows.txt. You could make a directory under your home directory — named, say, vimhelp, with symbolic links to vim help files you want to keep handy.

As in vi, each file vim edits is copied into its own buffer. Each window is associated with an editor buffer. There can be more than one window per buffer; this is useful when you want to to see (and edit) two different parts of the same file. All of this, and more, is explained in the help section windows-intro. If you haven’t scrolled through the help window, you’ll probably see the name windows-intro a few lines down in this help topic, with its name between vertical bars: |windows-intro|. An easy way to get to the topic is to search for it: type /intro and press Return.

Putting the cursor somewhere between the bars and pressing Control-] (Control-right-square-bracket) jumps to that help topic. (If you’ve used the vi tags system before, you’ll recognize Control-].) Page through and have a look at the huge number of windowing commands. See why you’ll want to be familiar with the online help?

Most window commands start with Control-W. In the current situation, where you have just two windows, the easiest command for moving between windows is Control-W p or Control-W Control-P. This takes you to the previous window, which, if you have just two windows, is always the other window.

Windows from the Start

If you give vim and standard vi more than one filename on the command line, they’ll show only the first file (in a single window). You can jump between files with commands like :n and :e#.

However, if you start vim with -o file1 file2., it splits your terminal vertically into one window per file.

Using -O (uppercase“ o”) instead splits your window horizontally. This is useful if you have a wide terminal window — full-screen, for example — with a small font. You can pack a lot of related files side-by-side. Because vim can scroll side-to-side when lines are wider than their window (instead of wrapping lines), it’s easy to see the first few words on each log line and scroll right for more detail.

When you’re finishing your editing session, use the familiar command :wq to write and quit the file in each window, or :qa to quit all windows without writing.

Jerry Peek is a freelance writer and instructor who has used Unix and Linux for 25 years. He’s happy to hear from readers; see https://www.jpeek.com/contact.html.

[Read previous article] [Read next article]
[Read Jerry’s other Linux Magazine articles]