《Learning the vi editor》

projl

identifier. Be careful where you place the cursor; vi uses the "word"
under the cursor starting at the current cursor position, not the
entire word containing the cursor.

If you try to use the :tag command to read in a
new file and you haven't saved your current text
since the last time you changed it, vi will not let you
go to the new file. You must either write out your
current file with the :w command and then issue
:tag, or else type:

:tag! name

to override vi's reluctance to discard edits.

The Solaris 2.6 version of vi actually supports tag stacks. It
appears, however, to be completely undocumented in the Solaris
man pages. Because many, if not most, versions of UNIX vi don't do
tag stacking, we have moved the discussion of this feature to
Section 8.5.3, where tag stacking is introduced.

projl

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,
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:

鈥

projl

Enhanced tags

As described in Section 7.5.3 in Chapter 7, 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.

projl

[3] emacs users have been doing this since the beginning; it is one of the reasons that many are rather
fanatic about their editor.
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.

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
Editor X11 MS-Windows OS/2 BeOS Macintosh Amiga
elvis
vim
vile

projl

8.4 Extended Regular Expressions
The metacharacters available in vi's search and substitution regular expressions
are described in Section 6.3.1 in Chapter 6. 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 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.

projl

{...}

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
\}.

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:
鈥

projl

鈥

projl

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

projl

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
Command Function
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
Command Function
^]
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
Option Function
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

Keystrokes Results

projl

/getopt
Edit main.c and move to the call to getopt_long.
^]
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.

Keystrokes Results
8jf_ ^]
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;
^]
The editor moves to the definition of struct option in getopt.h. You
may now look over the comments explaining how it's used.