Search the Catalog
Learning the vi Editor, 6th Edition

Learning the vi Editor, 6th Edition

By Linda Lamb & Arnold Robbins
6th Edition November 1998
1-56592-426-6, Order Number: 4266
348 pages, $29.95

Sample Chapter 8:

vi Clones Feature Summary

8.1 And These Are My Brothers, Darrell, Darrell, and Darrell

There are a number of freely available "clones" of the vi editor. Appendix E, vi and the Internet, provides a pointer to a web site that lists all known vi clones. We have chosen to cover four of the most popular ones. They are:

  • Version 1.79 of Keith Bostic's nvi

  • Version 2.0 of Steve Kirkendall's elvis

  • Version 5.0 of Bram Moolenaar's vim

  • Version 7.4 of vile, by Kevin Buettner, Tom Dickey, and Paul Fox

The clones were written because the source code for vi is not freely available, making it impossible to either port vi to a non-UNIX environment or to study the code, and/or because UNIX vi (or another clone!) did not provide desired functionality. For example, UNIX vi often has limits on the maximum length of a line, and it cannot edit binary files. (The chapters on the various programs present more information about each one's history.)

Each program provides a large number of extensions to UNIX vi; often, several of the clones provide the same extensions, although usually not in an identical way. Instead of repeating the treatment of each common feature in each program's chapter, we have centralized the discussion here. You can think of this chapter as presenting "what the clones do," with each clone's chapter presenting "how the clone does it."

This chapter covers the following topics:

Multiwindow editing

This is the ability to split the screen into multiple "windows."[1] You can edit a different file in each window, or have several views into the same file. This is perhaps the single most important extension over regular vi.

[1] Note that these are not the windows that you find on X Window-based UNIX workstations, or under MS-Windows or the Apple Macintosh.

GUI interfaces

All of the clones except nvi can be compiled to support an X Window interface. If you have a system running X, use of the GUI version may be preferable to splitting the screen of an xterm (or other terminal emulator); the GUI versions generally provide such nice features as scrollbars and multiple fonts. The native GUIs of other operating systems may also be supported.

Extended regular expressions

All of the clones make it possible to match text using regular expressions that are similar or identical to those provided by the UNIX egrep(1) command.

Enhanced tags

As described in Section 7.5.3, "Using Tags" in Chapter 7, Advanced Editing, you can use the ctags program to build up a searchable database of your files. The clones make it possible to "stack" tags, by saving your current location when you do a tag search. You can then return to that location. Multiple locations can be saved in a Last In First Out (LIFO) order, producing a stack of locations.

Several of the vi clone authors and the author of at least one ctags clone have gotten together to define a standard form for an enhanced version of the ctags format. In particular, it is now easier to use the tags functionality with programs written in C++, which allows overloaded function names.

Improved editing facilities

All of the clones provide the ability to edit the ex command line, "infinite undo" capability, arbitrary length lines and eight-bit data, incremental searching, (at least an option) to scroll the screen left to right for long lines instead of wrapping long lines, and mode indicators, as well as other features.

Programming assistance

Several of the editors provide features that allow you to stay within the editor during the typical "edit-compile-debug" cycle of software development.

Syntax highlighting

In elvis, vim, and vile, you can arrange to display different parts of a file in different colors and/or fonts. This is particularly useful for editing program source code.

There is one additional feature in the clones that we have chosen not to cover: extension languages. As of May 1998, nvi has preliminary support for Perl and Tcl integration, elvis has its own C-like expression evaluator,[2] vim has a C-like expression evaluator, plus support for Perl, Python, and Tcl integration, and vile, which has always had its own built-in extension language, has preliminary support for Perl integration. The extension language integration and support are very recent for all of the programs and will undoubtedly change significantly. For this reason, any discussion of the extension language facilities would be obsolete almost as soon as this book goes to press.

[2] The elvis 2.0 documentation mentions that "someday" elvis will have a true extension language, most likely Perl, but probably not for version 2.1. Steve Kirkendall doesn't really consider the expression evaluator to be an extension language.

We recommend that you check the online documentation for your clone if you're interested in programming your editor with an extension language.[3] Extension languages are a feature worth watching; they promise to bring a new dimension of power to vi users. The use of well-known programming languages, such as Perl, Python, and Tcl, is an additional advantage, since it is likely that users will already know one or more of them.

[3] emacs users have been doing this since the beginning; it is one of the reasons that many are rather fanatic about their editor.

[Chapter 8] 8.2 Multiwindow Editing

8.2 Multiwindow Editing

Perhaps the single most important feature that the clones offer over standard vi is the ability to edit files in multiple "windows." This makes it possible to easily work on more than one file at the same time, and to "cut and paste" text from one file to another via yanking and putting.[4]

[4] In the clones, you need not split the screen to yank and put between files; only the original vi discards the cut buffers when switching between files.

There are two fundamental concepts underlying each editor's multiwindow implementation, buffers and windows.

A buffer holds text to be edited. The text may come from a file, or it may be brand new text to eventually be written to a file. Any given file has only one buffer associated with it.

A window provides a view into a buffer, allowing you to see and modify the text in the buffer. There may be multiple windows associated with the same buffer. Changes made to the buffer in one window are reflected in any other windows open on the same buffer. A buffer may also have no windows associated with it. In this case, you can't do a whole lot with the buffer, although you can open a window on it later. Closing the last window open on a buffer effectively "hides" the file. If the buffer has been modified but not written to disk, the editor may or may not let you close the last window that's open on it.

When you create a new window, the editor splits the current screen. For most of the editors, you create a new window which shows another view on the file you're currently editing. You then switch to the window where you wish to edit the next file, and instruct the editor to start editing the file there. Each editor provides vi and ex commands to switch back and forth between windows, as well as the ability to change the window size, and hide and restore windows.

In each editor's chapter, we show a sample split screen (editing the same two files), and describe how to split the screen and move between windows.

[Chapter 8] 8.3 GUI Interfaces

8.3 GUI Interfaces

elvis, vim, and vile also provide graphical user interface (GUI) versions that can take advantage of a bit-mapped display and mouse. Besides supporting X Windows under UNIX, support for MS-Windows or other windowing systems may also be available. Table 8.1 summarizes the available GUIs for the different clones.

Table 8.1: Available GUIs
EditorX11MS-WindowsOS/2BeOSMacintoshAmiga
elvisXXX
vimXXXXXX
vileXXX
[Chapter 8] 8.4 Extended Regular Expressions

8.4 Extended Regular Expressions

The metacharacters available in vi's search and substitution regular expressions are described in Section 6.3.1, "Metacharacters Used in Search Patterns " in Chapter 6, Global Replacement. Each of the clones provides some form of extended regular expressions, either as an option or always available. Typically these are the same (or almost the same) as what's provided by egrep. Unfortunately, each one's extended flavor is slightly different from the others'.

To give you a feel for what extended regular expressions can do, we present them in the context of nvi. Each clone's chapter then describes that editor's extended syntax, without repeating the examples.

nvi extended regular expressions are the Extended Regular Expressions (EREs) as defined by the POSIX standard. In order to enable this feature, use set extended from either your .nexrc file or from the ex colon prompt.

Besides the standard metacharacters described in Chapter 6, and the POSIX bracket expressions mentioned in Section 6.3.2, "POSIX Bracket Expressions" in the same chapter, the following metacharacters are available:

|

Indicates alternation. For example, a|b matches either a or b. However, this construct is not limited to single characters: house|home matches either of the strings house or home.

(...)

Used for grouping, to allow the application of additional regular expression operators. For example, house|home can be shortened (if not simplified) to ho(use|me). The * operator can be applied to text in parentheses: (house|home)* matches home, homehouse, househomehousehouse and so on.

When extended is set, text grouped with parentheses acts like text grouped in \(...\) in regular vi; the actual text matched can be retrieved in the replacement part of a substitute command with \1, \2, etc. In this case, \( represents a literal left parenthesis.

+

Matches one or more of the preceding regular expressions. This is either a single character, or a group of characters enclosed in parentheses. Note the difference between + and *. The * is allowed to match nothing, but with + there must be at least one match. For example, ho(use|me)* matches ho as well as home and house, but ho(use|me)+ will not match ho.

?

Matches zero or one occurrence of the preceding regular expression. This indicates "optional" text that is either present or not present. For example, free?d will match either fred or freed, but nothing else.

{...}

Defines an interval expression. Interval expressions describe counted numbers of repetitions. In the description below, n and m represent integer constants.

{n}

Matches exactly n repetitions of the previous regular expression. For example, (home|house){2} matches homehome, homehouse, househome, and househouse, but nothing else.

{n,}

Matches n or more repetitions of the previous regular expression. Think of it as "as least n" repititions.

{n,m}

Matches n to m repititions. The bounding is important, since it controls how much text would be replaced during a substitute command.[5]

[5] The *, +, and ? operators can be reduced to {0,}, {1,} and {0,1} respectively, but they are much more convenient to use.

When extended is not set, nvi provides the same functionality with \{ and \}.

[Chapter 8] 8.5 Enhanced Tags

8.5 Enhanced Tags

The "Exuberant ctags" program is a ctags clone that is considerably more capable than UNIX ctags. It produces an extended tags file format that makes tag searching and matching a more flexible and capable process. We describe it first, since it is supported by several of the vi clones.

This section also describes tag stacks: the ability to save multiple locations visited with the :tag or ^] commands. All of the clones provide tag stacking.

8.5.1 Exuberant ctags

The "Exuberant ctags" program was written by Darren Hiebert. Its home page is http://home.hiwaay.net/~darren/ctags/. As of this writing, the current version is 2.0.3. The following list of the program's features is adapted from the README file in the ctags distribution:

Exuberant ctags produces tags files in the form described in the next subsection.

8.5.2 The New tags Format

Traditionally, a tags file has three tab-separated fields: the tag name (typically an identifier), the source file containing the tag, and an indication of where to find the identifier. This indication is either a simple line number, or a nomagic search pattern enclosed either in slashes or question marks. Furthermore, the tags file is always sorted.

This is the format generated by the UNIX ctags program. In fact, many versions of vi allowed any command in the search pattern field (a rather gaping security hole). Furthermore, due to an undocumented implementation quirk, if the line ended with a semicolon and then a double-quote (;"), anything following those two characters would be ignored. (The double-quote starts a comment, as it does in .exrc files.)

The new format is backwards-compatible with the traditional one. The first three fields are the same: tag, filename, and search pattern. Exuberant ctags only generates search patterns, not arbitrary commands. Extended attributes are placed after a separating ;". Each attribute is separated from the next by a tab character, and consists of two colon-separated subfields. The first subfield is a keyword describing the attribute, the second is the actual value. Table 8.2 lists the supported keywords.

Table 8.2: Extended ctags Keywords
KeywordMeaning
kind

The value is a single letter that indicates the lexical type of the tag. It can be f for a function, v for a variable, and so on. Since the default attribute name is kind, a solitary letter can denote the tag's type (e.g., f for a function).

file

For tags that are "static", i.e., local to the file. The value should be the name of the file.

If the value is given as an empty string (just file:), it is understood to be the same as the filename field; this special case was added partly for the sake of compactness, and partly to provide an easy way to handle tags files that aren't in the current directory. The value of the filename field is always relative to the directory in which the tags file itself resides.

function

For local tags. The value is the name of function in which they're defined.

struct

For fields in a struct. The value is the name of the structure.

enum

For values in an enum data type. The value is the name of the enum type.

class

For C++ member functions and variables. The value is the name of the class.

scope

Intended mostly for C++ class member functions. It will usually be private for private members or omitted for public members, so users can restrict tag searches to only public members.

arity

For functions. The number of arguments.

If the field does not contain a colon, it is assumed to be of type kind. Here are some examples:

ARRAYMAXED      awk.h    427;"   d
AVG_CHAIN_MAX   array.c   38;"   d     file:
array.c         array.c    1;"   F

ARRAYMAXED is a C #define macro defined in awk.h. AVG_CHAIN_MAX is also a C macro but it is used only in array.c. The third line is a bit different: it is a tag for the actual source file! This is generated with the -i F option to Exuberant ctags, and allows you to give the command :tag array.c. More usefully, you can put the cursor over a filename and use the ^] command to go to that file.

Within the value part of each attribute, the characters backslash, tab, carriage return and newline should be encoded as \\, \t, \r, and \n, respectively.

Extended tags files may have some number of initial tags that begin with !_TAG_. These tags usually sort to the front of the file, and are useful for identifying which program created the file. Here is what Exuberant ctags generates:

!_TAG_FILE_FORMAT      2                /extended format; ..../
!_TAG_FILE_SORTED      1                /0=unsorted, 1=sorted/
!_TAG_PROGRAM_AUTHOR   Darren Hiebert   /darren@hiebert.com/
!_TAG_PROGRAM_NAME     Exuberant Ctags  //
!_TAG_PROGRAM_URL      http://home.hiwaay.net/~darren/ctags   /.../
!_TAG_PROGRAM_VERSION  2.0.3            /with C++ support/

Editors may take advantage of these special tags to implement special features. For example, vim pays attention to the !_TAG_FILE_SORTED tag and will use a binary search to search the tags file instead of a linear search if the file is indeed sorted.

If you use tags files, we recommend that you get and install Exuberant ctags.

8.5.3 Tag Stacks

The :tag ex command and the ^] vi mode command provide a limited means of finding identifiers, based on the information provided in a tags file. Each of the clones extends this ability by maintaining a stack of tag locations. Each time you issue the :tag ex command, or use the ^] vi mode command, the editor saves the current location before searching for the specified tag. You may then return to a saved location using (usually) the ^T command or an ex command.

Solaris vi tag stacking and an example are presented below. The way each clone handles tag stacking is described in each editor's respective chapter.

8.5.3.1 Solaris vi

Surprisingly enough, the Solaris 2.6 version of vi supports tag stacking. Perhaps not so surprisingly, this feature is completely undocumented in the Solaris ex(1) and vi(1) manual pages. For completeness, we summarize Solaris vi tag stacking in Table 8.3, Table 8.4, and Table 8.5. Tag stacking in Solaris vi is quite simple.[6]

[6] This information was discovered based on experimentation. YMMV (your mileage may vary).

Table 8.3: Solaris vi Tag Commands
CommandFunction
ta[g][!] tagstring

Edit the file containing tagstring as defined in the tags file. The ! forces vi to switch to the new file if the current buffer has been modified but not saved.

po[p][!]

Pop the tag stack by one element.

Table 8.4: Solaris vi Command Mode Tag Commands
CommandFunction
^]

Look up the location of the identifier under the cursor in the tags file, and move to that location. If tag stacking is enabled, the current location is automatically pushed onto the tag stack.

^T

Return to the previous location in the tag stack, i.e., pop off one element.

Table 8.5: Solaris vi Options for Tag Management
OptionFunction
taglength, tl

Controls the number of significant characters in a tag that is to be looked up. The default value of zero indicates that all characters are significant.

tags, tagpath

The value is a list of filenames in which to look for tags. The default value is "tags /usr/lib/tags".

tagstack

When set to true, vi stacks each location on the tag stack. Use :set notagstack to disable tag stacking.

To give you a feel for using tag stacks, we present a short example, using Exuberant ctags and vim.

Suppose you are working with a program that uses the GNU getopt_long function, and that you need to understand more about it.

GNU getopt consists of three files, getopt.h, getopt.c, and getopt1.c.

First, you create the tags file, then you start by editing the main program, found in main.c:

$ ctags *.[ch]
$ ls
Makefile   getopt.c   getopt.h   getopt1.c   main.c   tags
$ vim main.c
KeystrokesResults
/getopt
Figure 8.0

Edit main.c and move to the call to getopt_long.

^]
Figure 8.0

Do a tag lookup on getopt_long. vim moves to getopt1.c, placing the cursor on the definition of getopt_long.

It turns out that getopt_long is a "wrapper" function for _getopt_internal. You place the cursor on _getopt_internal and do another tag search.

KeystrokesResults
8jf_ ^]
Figure 8.0

You have now moved to getopt.c. To find out more about struct option, move the cursor to option and do another tag search.

5jfo; ^]
Figure 8.0

The editor moves to the definition of struct option in getopt.h. You may now look over the comments explaining how it's used.

:tags
Figure 8.0

The :tags command in vim displays the tag stack.

Typing ^T three times would move you back to main.c, where you started. The tag facilities make it easy to move around as you edit source code.

[Chapter 8] 8.6 Improved Facilities

8.6 Improved Facilities

The four clones all provide additional features that make simple text editing easier and more powerful.

Editing the ex command line

The ability to edit ex mode commands as you type them, possibly including a saved history of ex commands. Also, the ability to complete filenames and possibly other things, such as commands and options.

No line length limit

The ability to edit lines of essentially arbitrary length. Also, the ability to edit files containing any 8-bit character.

Infinite undo

The ability to successively undo all of the changes you've made to a file.

Incremental searching

The ability to search for text while you are typing the search pattern.

Left/right scrolling

The ability to let long lines trail off the edge of screen instead of wrapping.

Visual mode

The ability to select arbitrary contiguous chunks of texts upon which some operation will be done.

Mode indicators

A visible indication of insert mode versus command mode, as well as indicators of the current line and column.

8.6.1 Command-Line History and Completion

Users of the csh, tcsh, ksh, and bash shells have known for years that being able to recall previous commands, edit them slightly, and resubmit them makes them more productive.

This is no less true for editor users than it is for shell users; unfortunately, UNIX vi does not have any facility to save and recall ex commands.

This lack is remedied in each of the clones. Although each one provides a different way of saving and recalling the command history, each one's mechanism is usable and useful.

In addition to a command history, all of the editors can do some kind of completion. This is where you type the beginning of, for example, a filename. You then type a special character (such as tab), and the editor completes the filename for you. All of the editors can do filename completion, some of them can complete other things as well. Details are provided in each editor's chapter.

8.6.2 Arbitrary Length Lines and Binary Data

All four clones can handle lines of any length.[7] Historic versions of vi often had limits of around 1,000 characters per line; longer lines would be truncated.

[7] Well, up to the maximum value of a C long, 2,147,483,647.

All four are also 8-bit clean, meaning that they can edit files containing any 8-bit character. It is even possible to edit binary and/or executable files, if necessary. This can be really useful, at times. You may or may not have to tell each editor that a file is binary.

nvi

Automatically handles binary data. No special command-line or ex options are required.

elvis

Under UNIX, does not treat a binary file differently from any other file. On other systems, it uses the elvis.brf file to set the binary option, to avoid newline translation issues. (The elvis.brf file and hex display modes are described in Section 10.10, "Interesting Features" in Chapter 10.)

vim

Does not have a limit on the length of a line. When binary is not set, vim is like nvi, and automatically handles binary data. However, when editing a binary file, you should either use the -b command-line option or :set binary. These set several other vim options that make it easier to edit binary files.

vile

Automatically handles binary data. No special command-line or ex options are required.

Finally, there is one tricky detail. Traditional vi always writes the file with a final newline appended. When editing a binary file, this might add one character to the file and cause problems. nvi and vim are compatible with vi by default, and add that newline. In vim you can set the binary option, so this doesn't happen. elvis and vile never append the extra newline.

8.6.3 Infinite Undo

UNIX vi allows you to undo only your last change, or to restore the current line to the state it was in before you started making any changes. All of the clones provide "infinite undo," the ability to keep undoing your changes, all the way back to the state the file was in before you started any editing.

8.6.4 Incremental Searching

When incremental searching is used, the editor moves the cursor through the file, matching text as you type the search pattern. When you finally type [RETURN], the search is finished.[8] If you've never seen it before, it is rather disconcerting at first, but after a while you get used to it.

[8] emacs has always had incremental searching.

elvis does not support incremental searching. nvi and vim enable incremental searching with an option, and vile uses two special vi mode commands. vile can be compiled with incremental searching disabled, but it is enabled by default. Table 8.6 shows the options each editor provides.

Table 8.6: Incremental Searching
EditorOptionCommandAction
nvisearchincr

The cursor moves through the file as you type, always being placed on the first character of the text that matches.

vimincsearch

The cursor moves through the file as you type. vim highlights the text that matches what you've typed so far.

vile^X S, ^X R

The cursor moves through the file as you type, always being placed on the first character of the text that matches. ^X S incrementally searches forward through the file, while ^X R incrementally searches backward.

8.6.5 Left-Right Scrolling

By default, vi and most of the clones wrap long lines around the screen. Thus, a single logical line of the file may occupy multiple physical lines on your screen.

There are times when it might be preferable if a long line simply disappeared off the right-hand edge of the screen, instead of wrapping. Moving onto that line and then moving to the right would "scroll" the screen sideways. This feature is available in all of the clones. Typically, a numeric option controls how much to scroll the screen, and a Boolean option controls whether lines wrap or disappear off the edge of the screen. vile also has command keys to perform sideways scrolling of the entire screen. Table 8.7 shows how to use horizontal scrolling with each editor.

Table 8.7: Sideways Scrolling
EditorScroll AmountOptionAction
nvisidescroll = 16leftright

Off by default. When set, long lines simply go off the edge of the screen. The screen scrolls left or right by 16 characters at a time.

elvissidescroll = 8wrap

Off by default. When set, long lines simply go off the edge of the screen. The screen scrolls left or right by 8 characters at a time.

vimsidescroll = 0wrap

Off by default. When set, long lines simply go off the edge of the screen. With sidescroll set to zero, each scroll puts the cursor in the middle of the screen. Otherwise the screen scrolls by the desired number of characters.

vilesideways = 0linewrap

Off by default. When set, long lines wrap. Thus, the default is to have long lines go off the edge of the screen. Long lines are marked at the left and right edges with < and >. With sideways set to zero, each scroll moves the screen by 1/3. Otherwise the screen scrolls by the desired number of characters.

horizscroll

On by default. When set, moving the cursor along a long line off-screen shifts the whole screen. When not set, only the current line shifts; this may be desirable on slower displays.

vile has two additional commands, ^X ^R and ^X ^L. These two commands scroll the screen right and left, respectively, leaving the cursor in its current location on the line. You cannot scroll so far that the cursor position would go off the screen.

8.6.6 Visual Mode

Typically, operations in vi apply to units of text such lines, words, or characters, or to sections of text from the current cursor position to a position specified by a search command. For example, d/^} deletes up to the next line that starts with a right brace. elvis, vim, and vile all provide a mechanism to explicitly select a region of text to which an operation will apply. In particular, it is possible to select a rectangular block of text and apply an operation to all the text within the rectangle! See each editor's respective chapter for the details.

8.6.7 Mode Indicators

As you know by now, vi has two modes, command mode and insert mode. Usually, you can't tell by looking at the screen which mode you're in. Furthermore, often it's useful to know where in the file you are, without having to use the ^G or ex := commands.

Two options address these issues, showmode and ruler. All four clones agree on the option names and meanings, and even Solaris vi has the showmode option.

Table 8.8 lists the special features in each editor.

Table 8.8: Position and Mode Indicators
EditorWith ruler, displaysWith showmode, displays
nvirow and column

insert, change, replace, and command mode indicators

elvisrow and column

input and command mode indicators

vimrow and column

insert, replace, and visual mode indicators

vilerow, column, and percent of file

insert, replace, and overwrite mode indicators

viN/A

separate mode indicators for open, input, insert, append, change, replace, replace one character, and substitute modes

The GUI versions of elvis and vim change the cursor shape depending upon the current mode.

[Chapter 8] 8.7 Programming Assistance

8.7 Programming Assistance

vi was developed primarily as a programmer's editor. It has features that make things especially easy for the UNIX programmer - someone writing C programs and troff documentation. (Real Programmers write Real Documentation in troff.) Several of the clones are proud bearers of this tradition, adding a number of features that make them even more usable and capable for the "power user."[9]

[9] In contrast to the What You See Is What You Get (WYSIWYG) philosophy, UNIX is the You Asked For It, You Got It operating system. (With thanks to Scott Lee.)

Two features (among many) most deserve discussion:

Edit-compile speedup

elvis, vim, and vile allow you to easily invoke make(1), capture the errors from your compiler, and automatically move to the lines containing the errors. You can then fix the errors and re-run make, all from within the editor.

Syntax highlighting

elvis, vim, and vile have the ability to highlight and/or change the color of different syntactic elements in different kinds of files.

8.7.1 Edit-Compile Speedup

Programming often consists of a "compile-test-debug" cycle. You make changes, compile the new code, and then test and debug it. When learning a new language, syntax errors are especially common, and it is frustrating to be constantly stopping and restarting (or suspending and resuming) the editor in between compiles.

elvis, vim, and vile all provide facilities that allow you to stay within the editor while compiling your program. Furthermore, they capture the compiler's output and use it to automatically go to each line that contains an error.[10] Consistent use of this ability can save time and improve programmer productivity.

[10] Yet another feature that emacs users are accustomed to comes to vi.

Here is an example, using elvis. You are beginning to learn C++, so you start out with the obligatory first program:

KeystrokesResults
:w hello.C
Figure 8.0

You enter the program, forgetting the closing quote, and then write the program to hello.C.

:make hello
Figure 8.0

You type the :make command to run make, which in turn runs the C++ compiler. (In this case, g++.)

:errlist
Figure 8.0

The :errlist command moves to the line with the error and displays the first compiler error message in the status line.

You can fix the error, resave the file, re-run :make and eventually compile your program without errors.

All of the editors have similar facilities. They will all compensate for changes in the file, correctly moving you to subsequent lines with errors. More details are provided in each editor's chapter.

8.7.2 Syntax Highlighting

elvis, vim, and vile all provide some form of syntax highlighting. All three also provide syntax coloring, changing the color of different parts of the file on displays that can do so (such as under X11 or the Linux console). See each editor's chapter for more information.

[Chapter 8] 8.8 Editor Comparison Summary

8.8 Editor Comparison Summary

Most of the clones support most or all of the features described above. Table 8.9 summarizes what each editor supports. Of course, the table does not tell the full story; the details are provided in each one's individual chapter.

Table 8.9: Feature Summary Chart
Featurenvielvisvimvile
Multiwindow editingXXXX
GUIXXX
Extended regular expressionsXXXX
Enhanced tagsXXX
Tag stacksXXXX
Arbitrary length linesXXXX
8-bit dataXXXX
Infinite undoXXXX
Incremental searchingXXX
Left-right scrollingXXXX
Mode indicatorsXXXX
Visual modeXXX
Edit-Compile SpeedupXXX
Syntax HighlightingXXX
Multiple OS supportXXX
[Chapter 8] 8.9 A Look Ahead

8.9 A Look Ahead

The next four chapters cover nvi, elvis, vim, and vile, in that order. Each chapter has the following outline:

  1. Who wrote the editor, and why.

  2. Important command-line arguments.

  3. Online help and other documentation.

  4. Initialization - what files and environment variables the program reads, and in what order.

  5. Multiwindow editing.

  6. GUI interface(s), if any.

  7. Extended regular expressions.

  8. Improved editing facilities (tag stacks, infinite undo, etc.).

  9. Programming assistance (edit-compile speedup, syntax highlighting).

  10. Interesting features unique to the program.

  11. Where to get the sources, and what operating systems the editor runs on.

    All of the distributions are compressed with gzip, GNU zip. If you don't already have it, you can get gzip from ftp://ftp.gnu.org/pub/gnu/gzip-1.2.4.tar. The untar.c program available from the elvis ftp site is a very portable, simple program for unpacking gzip'ed tar files on non-UNIX systems.

Because each of these programs continues to undergo development, we have not attempted an exhaustive treatment of each one's features. Such would quickly become outdated. Instead, we have "hit the highlights," covering the features that you are most likely to need to know about and that are least likely to change as the program evolves. You should supplement this book with each one's online documentation if you need to know how to use every last feature of your editor.


oreilly.com Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
International | About O'Reilly | Affiliated Companies | Privacy Policy

© 2001, O'Reilly & Associates, Inc.