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 "i">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– admits it– his fingers were trained for "i">vi. In 1981, on an overloaded VAX
running BSD, "i">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, "i">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 "i">vim (see the download page, "http://www.vim.org/download.php" class=
). 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

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 "i">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 "i">vim isn’t the only other version of "i">vi. There are many. Some of the "i">vi limitations that alternate versions of "i">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 "i">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
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 "i">tags- like interface, just one example of how well
vim builds upon original "i">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 "i">ex line (starting with a colon, "c">:) 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 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 "c">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 "c">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 "c">:help and press Return to take you to the table of

2.Type :help
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
then Control-D to see all the
matching topics. As it did here, vim does
completion in a lot of cases, similar to "i">bash and other shells. For instance, "i">vim can automatically complete a file name when you open
a new file.

Let’s look at windows and help using the second

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 "c">’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
, 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 "c">*windows* in the string "c">*windows**buffers*. These are the two names for this
particular help topic. (So, at this point, if you type "c">:help buffers and press Return, the same help topic
should appear, but the cursor should land on the topic name

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 "i">/usr/share/vim/vim63/doc/windows.txt. You could make a
directory under your home directory– named, say, "i">vimhelp, with symbolic links to "i">vim help files you want to keep handy.

As in vi, each file "i">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 "i">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
, it splits your terminal "i">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 "story_link">http://www.jpeek.com/contact.html.

Comments are closed.