xemacs-beta: man/viper.texi comparison

comparison man/viper.texi @ 0:376386a54a3c r19-14

Import from CVS: tag r19-14

author	cvs
date	Mon, 13 Aug 2007 08:45:50 +0200
parents
children	ac2d302a0011

comparison

equal deleted inserted replaced

--1:000000000000
+:376386a54a3c
+% -*-texinfo-*-
+%
+\input texinfo
+@comment Using viper.info instead of viper in setfilename breaks DOS.
+@setfilename ../info/viper.info
+@comment @setfilename viper.info
+@iftex
+@finalout
+@end iftex
+@titlepage
+@title Viper Is a Package for Emacs Rebels
+@subtitle a Vi emulator for GNU Emacs 19 and XEmacs 19
+@subtitle June 1996, Viper Version 2.90
+@author Masahiko Sato (VIP 3.5)
+@author Aamod Sane (VIP 4.4)
+@author Michael Kifer (Viper)
+@page
+@vskip 0pt plus 1fill
+@end titlepage
+@unnumbered Distribution
+@noindent
+Copyright @copyright{} 1995, 1996 Free Software Foundation, Inc.
+Permission is granted to make and distribute verbatim copies of
+this manual provided the copyright notice and this permission notice
+are preserved on all copies.
+@ignore
+Permission is granted to process this file through TeX and print the
+results, provided the printed document carries copying permission
+notice identical to this one except for the removal of this paragraph
+(this paragraph not being relevant to the printed manual).
+@end ignore
+Permission is granted to copy and distribute modified versions of this
+manual under the conditions for verbatim copying, provided that the entire
+resulting derived work is distributed under the terms of a permission
+notice identical to this one.
+Permission is granted to copy and distribute translations of this manual
+into another language, under the same conditions as for modified versions.
+@ifinfo
+@node Top, Overview,, (DIR)
+@unnumbered Viper
+We believe that one or more of the following statements are adequate
+descriptions:
+@example
+Viper Is a Package for Emacs Rebels;
+it is a VI Plan for Emacs Rescue
+and/or a venomous VI PERil.
+@end example
+Technically speaking, Viper is a Vi emulation package for GNU Emacs 19 and
+XEmacs 19. Because of its reliance on minor mode keymaps, Viper will not
+work under Emacs 18. Viper implements most Vi and Ex commands. It gives you
+the best of both worlds: Vi keystrokes for editing combined with the GNU
+Emacs environment. Viper also fixes some common complaints with Vi
+commands.  This manual describes Viper, concentrating on the differences
+from Vi and new features of Viper.
+Viper, formerly known as VIP-19, was written by Michael Kifer.  It is based
+on VIP version 3.5 by Masahiko Sato and VIP version 4.4 by Aamod Sane.
+Viper tries to be compatible with these packages.
+Viper is intended to be usable without reading this manual --- the defaults
+are set to make Viper as close to Vi as possible.  At startup, Viper will
+try to set the most appropriate default environment for you, based on
+your familiarity with Emacs. It will also tell you the basic GNU Emacs window
+management commands to help you start immediately.
+Although this manual explains how to customize Viper, some basic
+familiarity with Emacs Lisp would be a plus.
+It is recommended that you read the Overview node. The other nodes may
+be visited as needed.
+Comments and bug reports are welcome.
+@code{kifer@@cs.emacs.edu} is the current address for Viper bug reports.
+Please use the Ex command @kbd{:submitReport} for this purpose.@refill
+@end ifinfo
+@menu
+* Overview::                    Must read to get started
+* Improvements over Vi::        New features, Improvements
+* Customization::               How to customize Viper
+* Commands::                    Vi and Ex Commands
+* Key Index::                   Index of Vi and Ex Commands
+* Function Index::              Index of Viper Functions
+* Variable Index::              Index of Viper Variables
+* Package Index::               Index of Packages Mentioned in this Document
+* Concept Index::               Vi, Ex and Emacs concepts
+* Acknowledgments::
+@end menu
+@iftex
+@unnumbered Introduction
+We believe that one or more of the following statements are adequate
+descriptions:
+@example
+Viper Is a Package for Emacs Rebels;
+it is a VI Plan for Emacs Rescue
+and/or a venomous VI PERil.
+@end example
+Technically speaking, Viper is a Vi emulation package for GNU Emacs 19 and
+XEmacs 19. Because of its reliance on minor mode keymaps,
+it will not work under Emacs 18. Viper contains virtually all of
+Vi and Ex functionality and much more. It gives you the best of both
+worlds: Vi keystrokes for editing combined with the GNU Emacs
+environment. Viper also fixes some common complaints with Vi commands.
+This manual describes Viper, concentrating on the differences from Vi and
+on the new features of Viper.
+Viper, formerly known as VIP-19, was written by Michael Kifer.  It is based
+on VIP version 3.5 by Masahiko Sato and VIP version 4.4 by Aamod Sane.
+Viper tries to be compatible with these packages.
+Viper is intended to be usable without reading this manual --- the defaults
+are set to make Viper as close to Vi as possible.  At startup, Viper will
+attempt to set the most appropriate default environment for you, based on
+your familiarity with Emacs. It will also tell you the basic GNU Emacs window
+management commands to help you start immediately.
+Although this manual explains how to customize Viper, some basic
+familiarity with Emacs Lisp would be a plus.
+It is recommended that you read the chapter Overview. The other chapters
+will be useful for customization and advanced usage.
+You should also learn to use the Info on-line hypertext manual system that
+comes with Emacs. This manual can be read as an Info file. Try the command
+@kbd{ESC x info} with vanilla Emacs sometime.
+Comments and bug reports are welcome.
+@code{kifer@@cs.sunysb.edu} is the current address for Viper bug reports.
+Please use the Ex command @kbd{:submitReport} for this purpose.@refill
+@end iftex
+@node Overview,Improvements over Vi,Top,Top
+@chapter Overview of Viper
+Viper is a Vi emulation on top of Emacs. At the same time, Viper provides a
+virtually unrestricted access to Emacs facilities. Perfect compatibility
+with Vi is possible but not desirable. This chapter tells you about the
+Emacs ideas that you should know about, how to use Viper within Emacs and
+some incompatibilities.
+Viper was formerly known as VIP-19, which was
+a descendant of VIP 3.5 by Masahiko Sato and VIP 4.4 by Aamod Sane.
+@menu
+* Emacs Preliminaries::         Basic concepts in Emacs.
+* Loading Viper::                       Loading and Preliminary Configuration.
+* States in Viper::             Viper has four states orthogonal to
+modes in Emacs.
+* The Minibuffer::              Command line in Emacs.
+* Multiple Files in Viper::     True multiple file handling.
+* Unimplemented Features::      That are unlikely to be implemented.
+@end menu
+@node Emacs Preliminaries, Loading Viper, Overview, Overview
+@section Emacs Preliminaries
+@cindex buffer
+@cindex point
+@cindex mark
+@cindex text
+@cindex looking at
+@cindex end (of buffer)
+@cindex end (of line)
+@cindex region
+Emacs can edit several files at once. A file in Emacs is placed in a
+@dfn{buffer} that usually has the same name as the file. Buffers are also used
+for other purposes, such as shell interfaces, directory editing, etc.
+@xref{Dired,,Directory Editor,emacs,The
+Gnu Emacs Manual}, for an example.@refill
+A buffer has a distinguished position called the @dfn{point}.
+A @dfn{point} is always between 2 characters, and is @dfn{looking at}
+the right hand character. The cursor is positioned on the right hand
+character. Thus, when the @dfn{point} is looking at the end-of-line,
+the cursor is on the end-of-line character, i.e. beyond the last
+character on the line. This is the default Emacs behavior.@refill
+The default settings of Viper try to mimic the behavior of Vi,
+preventing the cursor from going beyond the last character on the line.
+By using Emacs commands directly (such as those bound to arrow keys), it is
+possible
+to get the cursor beyond the end-of-line. However, this won't (or shouldn't)
+happen if you restrict yourself to standard Vi keys, unless you modify the
+default editing style. @xref{Customization}.@refill
+In addition to the @dfn{point}, there is another distinguished buffer
+position called the @dfn{mark}. @xref{Mark,,Mark,emacs,The GNU Emacs
+manual}, for more info on the mark. The text between the @dfn{point} and the
+@dfn{mark} is called the @dfn{region} of the buffer. For the Viper user,
+this simply means that in addition to the Vi textmarkers a--z, there is
+another marker called @dfn{mark}. This is similar to the unnamed Vi marker
+used by the jump commands (`` and ''), which move the cursor to the
+position of the last absolute jump.
+Viper provides access to the region in most
+text manipulation commands as @kbd{r} and @kbd{R} suffix to commands
+that operate on text regions, e.g., @kbd{dr} to delete region, etc.
+@xref{Basics}, for more info.@refill
+@cindex window
+@cindex mode line
+@cindex buffer information
+@cindex Minibuffer
+@cindex command line
+@cindex buffer (modified)
+Emacs divides the screen into tiled @dfn{windows}. You can see the
+contents of a buffer through the window associated with the buffer.  The
+cursor of the screen is positioned on the character after @dfn{point}.
+Every window has a @dfn{mode line} that displays information about the buffer.
+You can change the format of the mode
+line, but normally if you see @samp{**} at the beginning of a mode line it
+means that the buffer is @dfn{modified}.  If you write out the contents of
+a buffer to a file, then the buffer will become not modified.  Also if
+you see @samp{%%} at the beginning of the mode line, it means that the file
+associated with the buffer is write protected. The mode line will also
+show the buffer name and current major and minor modes (see below).
+A special buffer called @dfn{Minibuffer} is displayed as the last line
+in a Minibuffer window. The Minibuffer window is used for command input
+output. Viper uses Minibuffer window for @kbd{/} and @kbd{:}
+commands.@refill
+@cindex mode
+@cindex keymap
+@cindex local keymap
+@cindex global keymap
+@cindex major mode
+@cindex minor mode
+An Emacs buffer can have a @dfn{major mode} that customizes Emacs for
+editing text of a particular sort by changing the functionality of the keys.
+Keys are defined using a @dfn{keymap} that records the bindings between
+keystrokes and
+functions. The @dfn{global keymap} is common to all the
+buffers.  Additionally, each buffer has its @dfn{local keymap} that determines the
+@dfn{mode} of the buffer.  If a function is bound to some key in the local
+keymap then that function will be executed when you type the key.
+If no function is bound to a key in the
+local map, however, the function bound to the key in the global map
+will be executed. @xref{Major Modes,Major Modes,Major Modes,emacs,The
+GNU Emacs Manual}, for more information.@refill
+A buffer can also have a @dfn{minor mode}. Minor modes are options that you
+can use or not. A buffer in @code{text-mode} can have @code{auto-fill-mode}
+as minor mode, which can be turned off or on at any time. In Emacs 19, a
+minor mode may have it own keymap, which overrides the local keymap when
+the minor mode is turned on.  For more information, @pxref{Minor
+Modes,Minor Modes,Minor Modes,emacs,The GNU Emacs Manual} @refill
+@cindex Viper as minor mode
+@cindex Control keys
+@cindex Meta key
+Viper is implemented as a collection of minor modes. Different minor modes
+are involved when Viper emulates Vi command mode, Vi insert mode, etc.
+You can also turn Viper on and off at any time while in Vi command mode.
+@xref{States in Viper}, for
+more information.@refill
+Emacs uses Control and Meta modifiers. These are denoted as C
+and M, e.g. @kbd{^Z} as @kbd{C-z} and @kbd{Meta-x} as @kbd{M-x}.
+The Meta key is usually located on each side of the Space bar; it is used
+in a manner similar to the Control key, e.g., @kbd{M-x} means typing
+@kbd{x} while holding the Meta key down.
+For keyboards that do not have a Meta key, @key{ESC} is used as Meta.
+Thus @kbd{M-x} is typed as @kbd{ESC x}. Viper uses @key{ESC} to switch
+from Insert state to Vi state. Therefore Viper defines @kbd{_} as its Meta
+key in Vi state. @xref{Vi State}, for more info.@refill
+Emacs is structured as a lisp interpreter around a C core. Emacs keys
+cause lisp functions to be called. It is possible to call these
+functions directly, by typing @kbd{M-x function-name}.
+@node Loading Viper, States in Viper, Emacs Preliminaries, Overview
+@section Loading Viper
+First, make sure that all six Viper files @file{viper*.el} are somewhere on
+Emacs @dfn{load path}. The load path is a list of directories where Emacs
+looks for its Lisp code; it is similar to Unix environment variable
+@var{PATH}.  The load path is determined by the Lisp variable
+@code{load-path}.
+Type @code{C-h v load-path RET} to check the current load path of your
+Emacs. (Here and later, @kbd{RET} stands for carriage return.) If the files
+@file{viper*.el} are not in any directory on the load path, you should
+create your own directory and put it on the load path; then put
+@file{viper*.el} in that directory.  To put a new directory, say
+@file{~/emacslib}, on your load path, add the following line at the
+beginning of your @file{~/.emacs} file:
+@lisp
+(setq load-path (cons "~/emacslib" load-path))
+@end lisp
+It is recommended that you compile @file{viper.el} by running
+@example
+make all
+@end example
+in the directory where Viper was unpacked. The best way to ensure that
+Viper is installed properly is to run
+@example
+make install
+@end example
+in the directory where Viper was unpacked. See README in the Viper
+distribution for the details on which modifications to the make file may be
+necessary.
+Once Viper is settled on the load path,
+the most common way to load it automatically is to include the line:
+@lisp
+(require 'viper)
+@end lisp
+@noindent
+in your @file{~/.emacs} file.  The @file{.emacs} file is placed in your home
+directory and it will be executed every time you invoke Emacs.
+Viper also uses the file @file{~/.vip} for Viper-specific customization.
+If you wish
+to be in Vi command state whenever this is appropriate, you can include the
+following
+line in your @file{.vip}:
+@lisp
+(setq vip-always t)
+@end lisp
+@noindent
+(@xref{Vi State}, for the explanation of Vi mode.)
+Once invoked, Viper will arrange to bring up Emacs buffers in Vi state
+whenever this makes sense.
+@xref{Packages that Change Keymaps}, to find out when forcing Vi command state
+on a buffer may be counter-productive.
+Even if your @file{.emacs} and @file{.vip} files do not contain any of the
+above lines, you can still load Viper and enter Vi state by typing the
+following from within Emacs:
+@lisp
+M-x load-library RET viper RET
+M-x viper-mode
+@end lisp
+@noindent
+Ask your local Emacs administrator if this fails to work.
+When Emacs first comes up, if you have not specified a file on the
+command line, it will show the @samp{*scratch*} buffer, in the
+@samp{Lisp Interaction} mode. After you invoke Viper, you can start
+editing files by using @kbd{:e}, @kbd{:vi}, or @kbd{v} commands.
+(@xref{File and Buffer Handling}, for more information on @kbd{v} and other
+new commands that, in many cases, are more convenient than @kbd{:e},
+@kbd{:vi}, and similar old-style Vi commands.)@refill
+@node States in Viper, The Minibuffer, Loading Viper,Overview
+@section States in Viper
+@kindex @kbd{C-z}
+@kindex @kbd{C-z}
+@kindex @kbd{ESC}
+@kindex @kbd{i}
+@cindex Emacs state
+@cindex Vi state
+@cindex Insert state
+@cindex Replace state
+@cindex Ex commands
+Viper has four states, Emacs, Vi, Insert, and Replace.
+@table @samp
+@item Emacs state
+This is the mode plain vanilla Emacs is normally in. After you have loaded
+Viper, @kbd{C-z} will normally take you to Vi command state. Another
+@kbd{C-z} will take you back to Emacs state.  This toggle key can be
+changed, @pxref{Customization} You can also type @kbd{M-x viper-mode} to
+change to Vi state.@refill
+For users who chose to set their user level to 1 at Viper setup time,
+switching to Emacs state is deliberately made harder in order to not
+confuse the novice user. In this case, @kbd{C-z} will either iconify Emacs
+(if Emacs runs as an application under X Windows) or it will stop Emacs (if
+Emacs runs on a dumb terminal or in an Xterm window).
+@item Vi state
+This is the Vi command mode. Any of the Vi commands, such as @kbd{i, o, a},
+@dots{}, will take you to Insert state. All Vi commands may
+be used in this mode. Most Ex commands can also be used.
+For a full list of Ex commands supported by Viper, type
+@kbd{:} and then @kbd{TAB}. To get help on any issue, including the Ex
+commands, type @kbd{:help}. This will invoke Viper Info
+(if it is installed). Then typing @kbd{i} will prompt you for a topic to
+search in the index. Note, to search for Ex commands in the index, you
+should start them with a ``@kbd{:}'', e.g., @kbd{:WW}.
+@item Insert state
+Insert state is the Vi insertion mode. @kbd{ESC} will take you back to
+Vi state. Insert state editing can be done, including auto-indentation. By
+default, Viper disables Emacs keybindings in Insert state.
+@item Replace state
+Commands like @kbd{cw} invoke the Replace state. When you cross the
+boundary of a replacement region (usually designated via a @samp{$} sign),
+it will automatically change to Insert state. You do not have to worry
+about it. The key bindings remain practically the same as in Insert
+state. If you type ESC, Viper will switch to Vi command mode, terminating the
+replacement state. @refill
+@end table
+@cindex mode line
+The modes are indicated on the @dfn{mode line} as <E>, <I>, <V>, and <R>,
+so that the multiple modes do not confuse you. Most of your editing can be
+done in Vi and Insert states. Viper will try to make all new buffers be in Vi
+state, but sometimes they may come up in Emacs state.  @kbd{C-z}
+will take you to Vi state in such a case.  In some major modes, like Dired,
+Info, Gnus, etc., you should not switch to Vi state (and Viper will not
+attempt to do so) because these modes are not intended for text editing and
+many of the Vi keys have special meaning there. If you plan to read news,
+browse directories, read mail, etc., from Emacs (which you should start
+doing soon!), you should learn about the meaning of the various keys in
+those special modes (typing @kbd{C-h m} in a buffer provides
+help with key bindings for the major mode of that buffer).
+If you switch to Vi in Dired or similar modes---no harm is
+done. It is just that
+the special keybindings provided by those modes will be temporarily
+overshadowed by Viper's bindings. Switching back to Viper's
+Emacs state will revive the environment provided by the current major mode.
+States in Viper are orthogonal to Emacs major modes, such as C mode or Dired
+mode. You can turn Viper on and off for any Emacs state. When Viper is turned
+on, Vi state can be used to move around. In Insert state, the bindings for
+these modes can be accessed.  For beginners (users at Viper levels 1 and 2),
+these bindings are suppressed in Insert state, so that new users are not
+confused by the Emacs states. Note that unless you allow Emacs bindings in
+Insert state, you cannot do many interesting things, like language
+sensitive editing. For the novice user (at Viper level 1), all major mode
+bindings are turned off in Vi state as well. This includes the bindings for
+key sequences that start with @kbd{C-c}, which practically means that all
+major mode bindings are supported.  @xref{Customization}, to find out how
+to allow Emacs keys in Insert state.
+@menu
+* Emacs State::         This is the state you should learn more about when
+you get up to speed with Viper.
+* Vi State::            Vi commands are executed in this state.
+* Insert State::        You can enter text, and also can do sophisticated
+editing if you know enough Emacs commands.
+* Replace State::       Like Insert mode, but it is invoked via the
+replacement commands, such as cw, C, R, etc.
+@end menu
+@node Emacs State, Vi State, States in Viper, States in Viper
+@subsection Emacs State
+@kindex @kbd{C-z}
+@cindex Emacs state
+You will be in this mode only by accident (hopefully). This is the state
+Emacs is normally in (imagine!!). Now leave it as soon as possible by
+typing @kbd{C-z}. The you will be in Vi state (sigh of relief) :-).
+Emacs state is actually a Viperism to denote all the major and minor modes
+(@xref{Emacs Preliminaries})  other than Viper that Emacs can be in. Emacs
+can have several modes, such as C mode for editing C programs, LaTeX mode
+for editing LaTeX documents, Dired for directory editing, etc. These are
+major modes, each with a different set of key-bindings. Viper states are
+orthogonal to these Emacs major modes. The presence of these language
+sensitive and other modes is a major win over Vi.  @xref{Improvements over
+Vi}, for more.@refill
+The bindings for these modes can be made available in the Viper Insert state
+as well as in Emacs state.  Unless you specify your user level as 1 (a
+novice), all major mode key sequences that start with @kbd{C-x} and
+@kbd{C-c} are also available in Vi state.  This is important because major
+modes designed for editing files, such as cc-mode or latex-mode, use key
+sequences that begin with @kbd{C-x} and @kbd{C-c}.
+There is also a key that lets you temporarily escape to Vi command state
+from Emacs state: typing @kbd{M-C-z} (or @kbd{ESC C-z}) will let
+you execute a single Vi command while staying in Viper's Emacs state.
+At present, this works only for 1-character Vi commands (and for some
+complex commands).
+@node Vi State, Insert State, Emacs State, States in Viper
+@subsection Vi State
+@cindex Vi state
+This is the Vi command mode. When Viper is in Vi state, you will see the sign
+<V> in the mode line. Most keys will work as in Vi. The notable
+exceptions are:
+@table @kbd
+@item C-x
+@kindex @kbd{C-x}
+@kbd{C-x} is used to invoke Emacs commands, mainly those that do window
+management. @kbd{C-x 2} will split a window, @kbd{C-x 0} will close a
+window. @kbd{C-x 1} will close all other windows. @kbd{C-xb} is used to
+switch buffers in a window, and @kbd{C-xo} to move through windows.
+These are about the only necessary keystrokes.
+For the rest, see the GNU Emacs Manual.
+@item C-c
+@kindex @kbd{C-c}
+For user levels 2 and higher, this key serves as a prefix key for the key
+sequences used by various major modes. For users at Viper level 1, @kbd{C-c}
+simply beeps.
+@item C-g and C-]
+@kindex @kbd{C-g}
+@kindex @kbd{C-]}
+These are the Emacs @samp{quit} keys.
+There will be cases where you will have to
+use @kbd{C-g} to quit. Similarly, @kbd{C-]} is used to exit
+@samp{Recursive Edits} in Emacs for which there is no comparable Vi
+functionality and no key-binding. Recursive edits are indicated by
+@samp{[]} brackets framing the modes on the mode line.
+@xref{Recursive Edit,Recursive
+Edit,Recursive Edit,emacs,The GNU Emacs Manual}.
+At user level 1, @kbd{C-g} is bound to @code{vip-info-on-file}
+function instead.
+@refill
+@item Underscore
+@kindex @kbd{_}
+@cindex Meta key
+Viper uses @kbd{ESC} as a switch between Insert and Vi states. Emacs uses
+@kbd{ESC} for Meta. We need a Meta key to call the Meta key functions
+such as @kbd{M-x function name}. The underscore key, @kbd{_}, was chosen,
+since it is the only reasonable, free Vi key left. Thus, in Vi state, to
+get @kbd{M-x}, you should type @kbd{_x} (if the keyboard has no Meta key).
+It is possible to use @kbd{ESC} as Meta, but then you cannot
+press @kbd{ESC} multiple times in Vi state. @xref{Customization}, to find
+out how to rebind ESC to be Meta.@refill
+@end table
+@noindent
+Other differences are mostly improvements. The ones you should know
+about are:
+@table @samp
+@item Undo
+@kindex @kbd{u}
+@kbd{u} will undo. Undo can be repeated by the @kbd{.} key. Undo itself
+can be undone. Another @kbd{u} will change the direction. The presence
+of repeatable undo means that @kbd{U}, undoing lines, is not very
+important. Therefore, @kbd{U} also calls @code{vip-undo}.
+@cindex multiple undo
+@cindex undo
+@item Counts
+Most commands, @kbd{~}, @kbd{[[}, @kbd{p}, @kbd{/}, @dots{}, etc., take counts.
+@comment ]] Just to balance parens
+@item Regexps
+Viper uses Emacs Regular Expressions for searches. These are a superset of
+Vi regular
+expressions, excepting the change-of-case escapes @samp{\u}, @samp{\L},
+@dots{}, etc. @xref{Regular Expressions,,Regular Expressions,emacs,The
+GNU Emacs Manual}, for details.
+Files specified to @kbd{:e} use @code{csh} regular expressions
+(globbing, wildcards, what have you).
+However, the function @code{vip-toggle-search-style}, bound to @kbd{C-c /},
+lets the user switch from search with regular expressions to plain vanilla
+search and vice versa. It also lets one switch from case-sensitive search
+to case-insensitive and back.
+@xref{Viper Specials}, for more details.
+@cindex regular expressions
+@cindex vanilla search
+@cindex case-sensitive search
+@cindex case-insensitive search
+@kindex @kbd{C-c /}
+@item Ex commands
+@cindex Ex commands
+The current working directory of a buffer is automatically inserted in the
+minibuffer if you
+type @kbd{:e} then space.
+Absolute filenames are required less often in Viper.
+For path names,
+Emacs uses a convention that is slightly different from that of Unix.
+It is designed to minimize the need for deleting path names that Emacs
+provides in its prompts. (This is usually convenient, but occasionally
+the prompt may suggest a wrong path name for you.) If you see a prompt
+@kbd{/usr/foo/} and you wish to edit the file @kbd{~/.vip}, you don't
+have to erase the prompt. Instead, simply continue typing what you
+need. Emacs will interpret @kbd{/usr/foo/~/.vip} correctly. Similarly,
+if the prompt is @kbd{~/foo/} and you need to get to @kbd{/bar/file}, keep
+typing. Emacs interprets @kbd{~/foo//bar/} as @kbd{/bar/file}, since when it
+sees @samp{//}, it understands that @kbd{~/foo/} is to be discarded.
+The command @kbd{:cd} will change the default directory for the
+current buffer. The command @kbd{:e} will interpret the
+filename argument in @code{csh}. @xref{Customization}, if you
+want to change the default shell.
+The command @kbd{:next} takes counts from
+@kbd{:args}, so that @kbd{:rew} is obsolete. Also, @kbd{:args} will show only
+the invisible files (i.e., those that are not currently seen in Emacs
+windows).
+When applicable, Ex commands support file completion and history. This
+means that by typing a partial file name and then @kbd{TAB}, Emacs will try
+to complete the name or it will offer a menu of possible completions.
+This works similarly to Tcsh and extends the behavior of Csh. While Emacs
+is waiting for a file name, you can type @kbd{M-p} to get the previous file
+name you typed. Repeatedly typing @kbd{M-p} and @kbd{M-n} will let you
+browse through the file history.
+Like file names, partially typed Ex commands can be completed by typing
+@kbd{TAB}, and Viper keeps the history of Ex commands. After typing
+@kbd{:}, you can browse through the previously entered Ex commands by
+typing @kbd{M-p} and @kbd{M-n}.  Viper tries to rationalize when it puts Ex
+commands on the history list.  For instance, if you typed @kbd{:w! foo},
+only @kbd{:w!}  will be placed on the history list. This is because the
+last history element is the default that can be invoked simply by typing
+@kbd{: RET}. If @kbd{:w! foo} were placed on the list, it would be all to
+easy to override valuable data in another file. Reconstructing the full
+command, @kbd{:w!  foo}, from the history is still not that hard, since Viper
+has a separate history for file names. By typing @kbd{: M-p}, you will get
+@kbd{:w!} in the Minibuffer. Then, repeated @kbd{M-p} will get you through
+the file history, inserting one file name after another.
+In contrast to @kbd{:w! foo}, if the command were @kbd{:r foo}, the entire
+command will appear in the history list. This is because having @kbd{:r}
+alone as a default is meaningless, since this command requires a file
+argument.
+@refill
+@end table
+@noindent
+As Vi, Viper's destructive commands can be re-executed by typing `@kbd{.}'.
+However, in addition, Viper keeps track of the history of such commands. This
+history can be perused by typing @kbd{C-c M-p} and @kbd{C-c M-n}.
+Having found the appropriate command, it can be then executed by typing
+`@kbd{.}'.
+@xref{Improvements over Vi}, for more information.
+@node Insert State, Replace State, Vi State, States in Viper
+@subsection Insert State
+@cindex Insert state
+To avoid confusing the beginner (at Viper level 1 and 2), Viper makes only the
+standard Vi keys available in Insert state. The implication is that
+Emacs major modes cannot be used Insert state.
+It is strongly recommended that as soon as you are comfortable, make the
+Emacs state bindings visible (by changing your user level to 3 or higher).
+@xref{Customization},
+to see how to do this.@refill
+Once this is done, it is possible to do quite a bit of editing in
+Insert state. For instance, Emacs has a @dfn{yank} command, @kbd{C-y},
+which is similar to Vi's @kbd{p}. However, unlike @kbd{p}, @kbd{C-y} can be
+used in Insert state of Viper. Emacs also has a kill ring where it keeps
+pieces of text you deleted while editing buffers. The command @kbd{M-y} is
+used to delete the text previously put back by Emacs' @kbd{C-y} or by Vi's
+@kbd{p} command and reinsert text that was placed on the kill-ring earlier.
+This works both in Vi and Insert states.
+In Vi state, @kbd{M-y} is a much better alternative to the usual Vi's way
+of recovering the 10 previously deleted chunks of text. In Insert state,
+you can
+use this as follows. Suppose you deleted a piece of text and now you need
+to re-insert it while editing in Insert mode. The key @kbd{C-y} will put
+back the most recently deleted chunk. If this is not what you want, type
+@kbd{M-y} repeatedly and, hopefully, you will find the chunk you want.
+Finally, in Insert and Replace states, Viper provides the history of
+pieces of text inserted in previous insert or replace commands.  These
+strings of text can be recovered by repeatedly typing @kbd{C-c M-p} or
+@kbd{C-c M-n} while in Insert or Replace state. (This feature is disabled
+in the minibuffer: the above keys are usually bound to other histories,
+which are more appropriate in the minibuffer.)
+@cindex Meta key
+You can call Meta functions from Insert state. The Vi-to-Emacs toggle key,
+normally @kbd{C-z}, is bound to Meta in Insert state. Thus @kbd{M-x} is
+typed as @kbd{C-zx}. The key @kbd{_} will now insert itself---it is not a
+Meta key in Insert state. (It is well understood that switching Meta keys
+around is inconvenient. However, there seems to be no way around this
+problem, short of changing Vi ESC key to something
+else. @xref{Customization}, for the information on @code{vip-ESC-key}, which
+can be used to free up @kbd{ESC} and designate some other key to do escape
+from Insert state to Vi state.)
+Other Emacs commands that are useful in Insert state are @kbd{C-e}
+and @kbd{C-a}, which move the cursor to the end and the beginning of the
+current line, respectively. You can also use @kbd{M-f} and @kbd{M-b},
+which move the cursor forward (or backward) one word.
+If your display has a Meta key, these functions are invoked by holding the
+Meta key and then typing @kbd{f} and @kbd{b}, respectively. On displays
+without the Meta key, these functions are invoked by typing
+@kbd{C-z f} and @kbd{C-z b} (@kbd{C-z} simulates the Meta key in Insert
+state, as explained above).
+When Viper is in Insert state, you will see <I> in the mode line.
+@node Replace State,, Insert State, States in Viper
+@subsection Replace State
+@cindex Replace state
+This state is entered through Vi replacement commands, such as @kbd{C},
+@kbd{cw}, etc., or by typing @kbd{R}. In Replace state, Viper puts <R> in the
+mode line to let you know which state is in effect. If Replace state is
+entered through @kbd{R}, Viper stays in that state until the user hits ESC.
+If this state is entered via the other replacement commands, then Replace
+state is in effect until you hit @kbd{ESC} or until you cross the rightmost
+boundary of the replacement region. In the latter case, Viper changes its
+state from Replace to Insert (which you will notice by the change in the
+mode line).
+Since Viper runs under Emacs, it is possible to switch between buffers
+while in Replace state. You can also move the cursor using the arrow keys
+(even on dumb terminals!) and the mouse. Because of this freedom (which is
+unattainable in regular Vi), it is possible to take the cursor outside the
+replacement region. (This may be necessary for several reasons, including
+the need to enable text selection and region-setting with the mouse.)
+The issue then arises as to what to do when the user
+hits the ESC key. In Vi, this would cause the text between cursor and
+the end of the replacement region to be deleted. But what if, as is
+possible in Viper, the cursor is not inside the replacement region?
+To solve the problem, Viper keeps track of the last cursor position while it
+was still inside the replacement region. So, in the above situation, Viper
+would delete text between this position and the end of the replacement
+region.
+@node The Minibuffer,Multiple Files in Viper, States in Viper, Overview
+@section The Minibuffer
+@cindex Minibuffer
+The Minibuffer is where commands are entered in. Editing can be done
+by commands from Insert state, namely:
+@table @kbd
+@item C-h
+Backspace
+@item C-w
+Delete Word
+@item C-u
+Erase line
+@item C-v
+Quote the following character
+@item RET
+Execute command
+@item C-g and C-]
+Emacs quit and abort keys. These may be necessary. @xref{Vi State}, for an
+explanation.
+@item M-p and M-n
+These keys are bound to functions that peruse minibuffer history. The
+precise history to be perused depends on the context. It may be the history
+of search strings, Ex commands, file names, etc.
+@end table
+Most of the Emacs keys are functional in the Minibuffer.  While in the
+Minibuffer, Viper tries to make editing resemble Vi's behavior when the
+latter is waiting for the user to type an Ex command. In particular, you
+can use the regular Vi commands to edit the Minibuffer. You can switch
+between the Vi state and Insert state at will, and even use the replace mode.
+Initially, the Minibuffer comes up in Insert state.
+Some users prefer plain Emacs bindings in the Minibuffer. To this end, set
+@code{vip-vi-style-in-minibuffer} to @code{nil} in @file{.vip}.
+@xref{Customization}, to learn how to do this.
+When the Minibuffer changes Viper states, you will notice that the appearance
+of the text there changes as well. This is useful because the Minibuffer
+has no mode line to tell which Vi state it is in.
+The appearance of the text in the Minibuffer can be changed.
+@xref{Viper Specials}, for more details.
+@node Multiple Files in Viper,Unimplemented Features,The Minibuffer,Overview
+@section Multiple Files in Viper
+@cindex multiple files
+@cindex managing multiple files
+Viper can edit multiple files. This means, for example that you never need
+to suffer through @code{No write since last change} errors.
+Some Viper elements are common over all the files.
+@table @samp
+@item Textmarkers
+@cindex markers
+@cindex textmarkers
+Textmarkers remember @emph{files and positions}.
+If you set marker @samp{a} in
+file @file{foo}, start editing file @file{bar} and type @kbd{'a}, then
+@emph{YOU WILL SWITCH TO FILE @file{foo}}. You can see the contents of a
+textmarker using the Viper command @kbd{[<a-z>} where <a-z> are the
+textmarkers, e.g., @kbd{[a} to view marker @samp{a} .@refill
+@item Repeated Commands
+Command repetitions are common over files. Typing @kbd{!!} will repeat the
+last @kbd{!} command whichever file it was issued from.
+Typing @kbd{.} will repeat the last command from any file, and
+searches will repeat the last search. Ex commands can be repeated by typing
+@kbd{:RET}.@refill
+Note: in some rare cases, that @kbd{:RET} may do something dangerous.
+However, usually its effect can be undone by typing @kbd{u}.
+@item Registers
+@cindex registers
+Registers are common to files. Also, text yanked with @kbd{y} can be
+put back (@kbd{p}) into any file. The Viper command @kbd{]<a-z>}, where <a-z> are
+the registers, can be used to look at the contents of a register, e.g.,
+type @kbd{]a} to view register @samp{a}.
+There is one difference in text deletion that you should be
+aware of. This difference comes from Emacs and was adopted in Viper
+because we find it very useful. In Vi, if you delete a line, say, and then
+another line, these two deletions are separated and are put back
+separately if you use the @samp{p} command. In Emacs (and Viper), successive
+series of deletions that are @emph{not interrupted} by other commands are
+lumped together, so the deleted text gets accumulated and can be put back
+as one chunk. If you want to break a sequence of deletions so that the
+newly deleted text could be put back separately from the previously deleted
+text, you should perform a non-deleting action, e.g., move the cursor one
+character in any direction.
+@item Absolute Filenames
+@cindex absolute paths
+The current directory name for a file is automatically prepended to the
+file name in any
+@kbd{:e}, @kbd{:r}, @kbd{:w}, etc., command (in Emacs, each buffer has a
+current directory).
+This directory is inserted in the Minibuffer once you type space after
+@kbd{:e, r}, etc. Viper also supports completion of file names and Ex
+commands (@kbd{TAB}), and it keeps track of
+command and file history (@kbd{M-p}, @kbd{M-n}).
+Absolute filenames are required less
+often in Viper.
+You should be aware that Emacs interprets @kbd{/foo/bar//bla} as
+@kbd{/bla} and @kbd{/foo/~/bar} as @kbd{~/bar}. This is designed to
+minimize the need for erasing path names that Emacs suggests in its
+prompts, if a suggested path name is not what you wanted.
+The command @kbd{:cd} will change the default directory for the
+current Emacs buffer. The Ex command @kbd{:e} will interpret the
+filename argument in @samp{csh}, by default. @xref{Customization}, if you
+want to change this.
+@end table
+@noindent
+Currently undisplayed files can be listed using the @kbd{:ar} command.  The
+command @kbd{:n} can be given counts from the @kbd{:ar} list to switch to
+other files.
+@node Unimplemented Features,,Multiple Files in Viper,Overview
+@section Unimplemented Features
+Unimplemented features include:
+@itemize @bullet
+@item
+@kbd{:ab} and @kbd{:una} are not implemented.
+Both @kbd{:map} and @kbd{:ab} are considered obsolete, since Emacs has much
+more powerful facilities for defining keyboard macros and abbreviations.
+@item
+@kbd{:set option?} is not implemented. The current
+@kbd{:set} can also be used to set Emacs variables.
+@item
+@kbd{:se list} requires modification of the display code for Emacs, so
+it is not implemented.
+A useful alternative is @code{cat -t -e file}. Unfortunately, it cannot
+be used directly inside Emacs, since Emacs will obdurately change @samp{^I}
+back to normal tabs.@refill
+@end itemize
+@comment  node-name,  next,  previous,  up
+@node Improvements over Vi, Customization, Overview, Top
+@chapter Improvements over Vi
+Some common problems with Vi and Ex have been solved in Viper. This
+includes better implementation of existing commands, new commands, and
+the facilities provided by Emacs.
+@menu
+* Basics::                  Basic Viper differences, Multi-file effects.
+* Undo and Backups::        Multiple undo, auto-save, backups and changes
+* History::                 History for Ex and Vi commands.
+* Macros and Registers::    Keyboard Macros (extended ".") @@reg execution.
+* Completion::              Filename and Command Completion for Ex.
+* Improved Search::         Incremental Search and Buffer Content Search.
+* Abbreviation Facilities:: Normal Abbrevs, Templates, and Dynamic Abbrevs.
+* Movement and Markers::    Screen Editor movements, viewing textmarkers.
+* New Commands::            Commands that do not exist in Vi.
+* Useful Packages::         A Sampling of some Emacs packages, and things
+you should know about.
+@end menu
+@node Basics, Undo and Backups, Improvements over Vi, Improvements over Vi
+@section Basics
+The Vi command set is based on the idea of combining motion commands
+with other commands. The motion command is used as a text region
+specifier for other commands.
+We classify motion commands into @dfn{point commands} and
+@dfn{line commands}.@refill
+@cindex point commands
+The point commands are:
+@quotation
+@kbd{h}, @kbd{l}, @kbd{0},  @kbd{$}, @kbd{w}, @kbd{W}, @kbd{b}, @kbd{B},
+@kbd{e}, @kbd{E}, @kbd{(}, @kbd{)}, @kbd{/}, @kbd{?}, @kbd{`}, @kbd{f},
+@kbd{F}, @kbd{t}, @kbd{T}, @kbd{%}, @kbd{;}, @kbd{,}, @kbd{^}
+@end quotation
+@cindex line commands
+The line commands are:
+@quotation
+@kbd{j}, @kbd{k}, @kbd{+}, @kbd{-}, @kbd{H}, @kbd{M}, @kbd{L}, @kbd{@{},
+@kbd{@}}, @kbd{G}, @kbd{'},  @kbd{[[}, @kbd{]]}, @kbd{[]}
+@end quotation
+@cindex region
+@cindex region specification
+@cindex expanding (region)
+@cindex describing regions
+@cindex movement commands
+@noindent
+If a point command is given as an argument to a modifying command, the
+region determined by the point command will be affected by the modifying
+command. On the other hand, if a line command is given as an argument to a
+modifying command, the region determined by the line command will be
+enlarged so that it will become the smallest region properly containing the
+region and consisting of whole lines (we call this process @dfn{expanding
+the region}), and then the enlarged region will be affected by the modifying
+command.
+Text Deletion Commands (@xref{Deleting Text}), Change commands
+(@xref{Changing Text}), even Shell Commands (@xref{Shell Commands})
+use these commands to describe a region of text to operate on.
+Thus, type @kbd{dw} to delete a word, @kbd{>@}} to shift a paragraph, or
+@kbd{!'afmt} to format a region from @samp{point} to textmarker
+@samp{a}.
+@cindex r and R region specifiers
+Viper adds the region specifiers @samp{r} and @samp{R}. Emacs has a
+special marker called @dfn{mark}. The text-area between the current cursor
+position @dfn{point} and the @dfn{mark} is called the @dfn{region}.
+@samp{r} specifies the raw region and @samp{R} is the expanded region
+(i.e., the minimal contiguous chunk of full lines that contains the raw
+region).
+@kbd{dr} will now delete the region, @kbd{>r} will shift it, etc.
+@kbd{r,R} are not motion commands, however. The special mark is set by
+@kbd{m.} and other commands. @xref{Marking}, for more info.
+Viper also adds counts to most commands for which it would make sense.
+In the Overview chapter, some Multiple File issues were discussed
+(@xref{Multiple Files in Viper}). In addition to the files, Emacs has
+buffers. These can be seen in the @kbd{:args} list and switched using
+@kbd{:next} if you type @kbd{:set ex-cycle-through-non-files t}, or
+specify @code{(setq ex-cycle-through-non-files t)} in your @file{.vip}
+file. @xref{Customization}, for details.
+@node Undo and Backups, History, Basics, Improvements over Vi
+@section Undo and Backups
+@cindex undo
+Viper provides multiple undo. The number of undo's and the size is limited
+by the machine. The Viper command @kbd{u} does an undo. Undo can be
+repeated by typing @kbd{.} (a period). Another @kbd{u} will undo the undo,
+and further
+@kbd{.} will repeat it. Typing @kbd{u} does the first undo, and changes the
+direction.
+@cindex backup files
+@cindex auto save
+Since the undo size is limited, Viper can create backup files and
+auto-save files. It will normally do this automatically. It is possible
+to have numbered backups, etc. For details, @pxref{Backup,,Backup and
+Auto-Save,emacs,The GNU Emacs Manual} @refill
+@comment [ balance parens
+@cindex viewing registers and markers
+@cindex registers
+@cindex markers
+@cindex textmarkers
+The results of the 9 previous changes are available in the 9 numeric
+registers, as in Vi. The extra goody is the ability to @emph{view} these
+registers, in addition to being able to access them through @kbd{p} and
+@kbd{M-y} (@xref{Insert State}, for details.)
+The Viper command @kbd{] register} will display the contents of any
+register, numeric or alphabetical. The related command @kbd{[ textmarker}
+will show the text around the textmarker. @samp{register} and @samp{textmarker}
+can be any letters from a through z.
+@comment ] balance parens
+@node History,  Macros and Registers, Undo and Backups,Improvements over Vi
+@section History
+@cindex history
+@cindex Minibuffer
+History is provided for Ex commands, Vi searches, file names, pieces of
+text inserted in earlier commands that use Insert or Replace state, and for
+destructive commands in Vi state. These are
+useful for fixing those small typos that screw up searches and @kbd{:s},
+and for eliminating routine associated with repeated typing of file names
+or pieces of text that need to be inserted frequently.
+At the @kbd{:} or @kbd{/} prompts in the Minibuffer, you can do the following:
+@table @kbd
+@item M-p and M-n
+To move to previous and next history items. This causes the history
+items to appear on the command line, where you can edit them, or
+simply type Return to execute.
+@item M-r and M-s
+To search backward and forward through the history.
+@item RET
+Type RET to accept a default (which is displayed in the prompt).
+@end table
+The history of insertions  can be perused by
+typing @kbd{C-c M-p} and @kbd{C-c M-n} while in Insert or Replace state.
+The history of destructive Vi commands can be perused via the same keys
+when Viper is in Vi state. @xref{Viper Specials}, for details.
+All Ex commands have a file history. For instance, typing @kbd{:e}, space
+and then @kbd{M-p} will bring up the name of the previously typed file
+name. Repeatedly typing @kbd{M-p}, @kbd{M-n}, etc., will let you browse
+through the file history.
+Similarly, commands that have to do with switching buffers
+have a buffer history, and commands that expect strings or regular
+expressions keep a history on those items.
+@node Macros and Registers,Completion,History,Improvements over Vi
+@section Macros and Registers
+@cindex keyboard macros
+@cindex macros
+@cindex registers
+@cindex register execution
+Viper facilitates the use of Emacs-style keyboard macros. @kbd{@@#} will
+start a macro definition.  As you type, the commands will be executed, and
+remembered (This is called ``learn mode'' in some editors.)
+@kbd{@@register} will complete the macro, putting it into @samp{register},
+where @samp{register} is any character from @samp{a} through @samp{z}. Then
+you can execute this macro using @kbd{@@register}. It is, of course,
+possible to yank some text into a register and execute it using
+@kbd{@@register}. Typing @kbd{@@@@}, @kbd{@@RET}, or @kbd{@@LF} will
+execute the last macro that was executed using @kbd{@@register}.@refill
+Viper will automatically lowercase the register, so that pressing the
+@kbd{SHIFT} key for @kbd{@@} will not create problems. This is for
+@kbd{@@} macros and @kbd{"p} @emph{only}. In the case of @kbd{y},
+@kbd{"Ayy} will append to @emph{register a}. For @kbd{[,],',`}, it
+is an error to use a Uppercase register name.
+@comment [ balance parens
+@cindex viewing registers and markers
+The contents of a register can be seen by @kbd{]register}. (@kbd{[textmarker}
+will show the contents of a textmarker).
+@comment ] balance parens
+@cindex last keyboard macro
+The last keyboard macro can also be executed using
+@kbd{*}, and it can be yanked into a register using @kbd{@@!register}.
+This is useful for Emacs style keyboard macros defined using @kbd{C-x(}
+and @kbd{C-x)}. Emacs keyboard macros have more capabilities.
+@xref{Keyboard Macros,,Keyboard Macros,emacs, The GNU Emacs Manual}, for
+details.@refill
+Keyboard Macros allow an interesting form of Query-Replace:
+@kbd{/pattern} or @kbd{n} to go to the next pattern (the query), followed by a
+Keyboard Macro execution @kbd{@@@@} (the replace).
+Viper also provides Vi-style macros. @xref{Vi Macros}, for details.
+@node Completion, Improved Search, Macros and Registers, Improvements over Vi
+@section Completion
+@cindex completion
+Completion is done when you type @kbd{TAB}. The Emacs completer does not
+grok wildcards in filenames. Once you type a wildcard, the completer will
+no longer work for that path.  Remember that Emacs interprets a file name
+of the form @kbd{/foo//bar} as @kbd{/bar} and @kbd{/foo/~/bar} as
+@kbd{~/bar}.
+@node Improved Search, Abbreviation Facilities, Completion, Improvements over Vi
+@section Improved Search
+@cindex buffer search
+@cindex word search
+Viper provides buffer search, the ability to search the buffer for a region
+under the cursor. You have to turn this on in @file{.vip} either by calling
+@example
+(vip-buffer-search-enable)
+@end example
+@noindent
+or by setting @code{vip-buffer-search-char} to, say, @kbd{f3}:
+@example
+(setq vip-buffer-search-char [f3])
+@end example
+@noindent
+If the user calls @code{vip-buffer-search-enable} explicitly (the first
+method), then @code{vip-buffer-search-char} will be set to @kbd{g}.
+Regardless of how this feature is enabled, the key
+@code{vip-buffer-search-char} will take movement commands, like
+@kbd{w,/,e}, to find a region and then search for the contents of that
+region. This command is very useful for searching for variable names, etc.,
+in a program. The search can be repeated by @kbd{n} or reversed by @kbd{N}.
+@cindex incremental search
+Emacs provides incremental search. As you type the string in, the
+cursor will move to the next match. You can snarf words from the buffer
+as you go along. Incremental Search is normally bound to @kbd{C-s} and
+@kbd{C-r}. @xref{Customization}, to find out how to change the bindings
+of @kbd{C-r or C-s}.
+For details, @pxref{Incremental Search,,Incremental
+Search,emacs,The GNU Emacs Manual} @refill
+@cindex query replace
+Viper also provides a query replace function that prompts through the
+Minibuffer. It is invoked by the @kbd{Q} key in Vi state.
+@cindex mouse search
+On a window display, Viper supports mouse search, i.e., you can search for a
+word by clicking on it. @xref{Viper Specials}, for details.
+Finally, on a window display, Viper highlights search patterns as it finds
+them. This is done through what is known as @emph{faces} in Emacs. The
+variable that controls how search patterns are highlighted is
+@code{vip-search-face}.
+If you don't want any highlighting at all, put
+@example
+(copy-face 'default 'vip-search-face)
+@end example
+@vindex @code{vip-search-face}
+@noindent
+in @file{~/.vip}. If you want to change how patterns are highlighted, you
+will have to set the variable @code{vip-search-face} to some other face,
+such as @code{highlight}. If none of the existing faces fits the bill, you
+may have to create your own. Further details on faces can be found
+in the Emacs Lisp Manual.
+@node Abbreviation Facilities,Movement and Markers,Improved Search,Improvements over Vi
+@section Abbreviation Facilities
+@cindex abbrevs
+It is possible in Emacs to define abbrevs based on the contents of the
+buffer.
+Sophisticated templates can be defined using the Emacs abbreviation
+facilities. @xref{Abbrevs,,Abbreviations,emacs,The GNU Emacs Manual}, for
+details.
+@cindex dynamic abbrevs
+Emacs also provides Dynamic Abbreviations. Given a partial word, Emacs
+will search the buffer to find an extension for this word. For instance,
+one can type @samp{Abbreviations} by typing @samp{A}, followed by a keystroke
+that completed the @samp{A} to @samp{Abbreviations}. Repeated typing
+will search further back in the buffer, so that one could get
+@samp{Abbrevs} by repeating the
+keystroke, which appears earlier in the text. Emacs binds this to
+@kbd{ESC /}, so you will have to find a key and bind the function
+@code{dabbrev-expand} to that key.
+Facilities like this make Vi's @kbd{:ab} command obsolete.
+@node Movement and Markers, New Commands, Abbreviation Facilities, Improvements over Vi
+@section Movement and Markers
+@cindex Ex style motion
+@cindex line editor motion
+Viper can be set free from the line--limited movements in Vi, such as @kbd{l}
+refusing to move beyond the line, @kbd{ESC} moving one character back,
+etc. These derive from Ex, which is a line editor. If your @file{.vip}
+contains
+@example
+@code{(setq vip-ex-style-motion nil)}
+@end example
+@noindent
+the motion will be a true screen editor motion. One thing you must then
+watch out for is that it is possible to be on the end-of-line character.
+The keys @kbd{x} and @kbd{%} will still work correctly, i.e., as if they
+were on the last character.
+@vindex @code{vip-syntax-preference}
+@cindex syntax table
+The word-movement commands @kbd{w}, @kbd{e}, etc., and the associated
+deletion/yanking commands, @kbd{dw}, @kbd{yw}, etc., can be made to
+understand Emacs syntax tables. If the variable
+@code{vip-syntax-preference} is set to @code{'strict-vi} (the default) then
+the meaning of @emph{word} is the same as in
+Vi. However, if the value is @code{'reformed-vi} then the alphanumeric
+symbols will be those specified by the current Emacs syntax table (which
+may be different for different major modes) plus the underscore symbol
+@code{_}. The user can also specify the value @code{'emacs}, which would
+make Viper use exactly the Emacs notion of word. In particular, the
+underscore may not be part of a word. Finally, if
+@code{vip-syntax-preference} is set to @code{'extended}, Viper words would
+consist of characters that are classified as alphanumeric @emph{or} as
+parts of symbols. This is convenient for writing programs and in many other
+situations.
+@code{vip-syntax-preference} is a local variable, so it can have different
+values for different major modes. For instance, in programming modes it can
+have the value @code{'extended}. In text modes where words contain special
+characters, such as European (non-English) letters, Cyrillic letters, etc.,
+the value can be @code{'reformed-vi} or @code{'emacs}.
+Changes to @code{vip-syntax-preference} should be done in the hooks to
+various major modes. Furthermore, for these changes to take effect, you
+should execute @code{(vip-update-alphanumeric-class)} right after changing
+The above discussion of the meaning of Viper's words concerns only Viper's
+movement commands. In regular expressions, words remain the same as in
+Emacs.  That is, the expressions @code{\w}, @code{\>}, @code{\<}, etc., use
+Emacs' idea of what is a word, and they don't look into the value of
+variable @code{vip-syntax-preference}. This is because Viper doesn't change
+syntax tables in fear of upsetting the various major modes that set these
+tables.
+@cindex textmarkers
+Textmarkers in Viper remember the file and the position, so that you can
+switch files by simply doing @kbd{'a}. If you set up a regimen for using
+Textmarkers, this is very useful. Contents of textmarkers can be viewed
+by @kbd{[marker}. (Contents of registers can be viewed by @kbd{]register}).
+@node New Commands, Useful Packages, Movement and Markers, Improvements over Vi
+@section New Commands
+These commands have no Vi analogs.
+@table @kbd
+@item C-x, C-c
+@kindex @kbd{C-x}
+@kindex @kbd{C-c}
+@kbd{C-x} will exit from Vi state and return to Emacs state
+@emph{temporarily}. If
+you hit one of these keys, Emacs will believe
+that you hit that key in Emacs state. For example, if you hit @kbd{C-x}
+followed by @kbd{2}, then the current window will be split into 2 and you
+will be in Vi state again. Except for novice users, @kbd{C-c} is also set
+to temporarily escape to Emacs and execute a command from the current
+major mode.
+@kbd{ESC} will do the same, if
+you configure @key{ESC} as Meta by setting @code{vip-no-multiple-ESC} to nil
+in @file{.vip}. @xref{Customization}. @kbd{C-z}
+in Insert state will make Emacs think @kbd{Meta} has been hit.@refill
+@item \
+@kindex @kbd{\}
+Escape to Emacs to execute a single Emacs command. For instance, @kbd{\
+ESC} will act like a Meta key.
+@item Q
+@kindex @kbd{Q}
+@cindex query replace
+@kbd{Q} is for query replace.  By default,
+each string to be replaced is treated as a regular expression. You can use
+@code{(setq vip-re-query-replace nil)} in your @file{.emacs} file to
+turn this off. (For normal searches, @kbd{:se nomagic} will work. Note
+that @kbd{:se nomagic} turns Regexps off completely, unlike Vi).
+@item v
+@itemx V
+@itemx C-v
+@kindex @kbd{v}
+@kindex @kbd{V}
+@kindex @kbd{C-v}
+These keys are used to visit files.  @kbd{v} will switch to a buffer
+visiting file whose name can be entered in the Minibuffer. @kbd{V} is
+similar, but will use a window different from the current window.
+@kbd{C-v} is like @kbd{V}, except that a new frame (X window) will be used
+instead of a new Emacs window.
+@item #
+@kindex @kbd{#}
+If followed by a certain character @var{ch}, it becomes an operator whose
+argument is the region determined by the motion command that follows
+(indicated as <move>).
+Currently, @var{ch} can be one of @kbd{c}, @kbd{C}, @kbd{g}, @kbd{q}, and
+@kbd{s}. For instance, @kbd{#qr} will prompt you for a string and then
+prepend this string to each line in the buffer.@refill
+@item # c
+@kindex @kbd{#c<move>}
+@cindex changing case
+Change upper case characters in the region to lower case
+(@code{downcase-region}).
+Emacs command @kbd{M-l} does the same for words.
+@item # C
+@kindex @kbd{#C<move>}
+Change lower case characters in the region to upper case. For instance,
+@kbd{# C 3 w} will capitalize 3 words from the current point
+(@code{upcase-region}).
+Emacs command @kbd{M-u} does the same for words.
+@item # g
+@kindex @kbd{#g<move>}
+Execute last keyboard macro for each line in the region
+(@code{vip-global-execute}).@refill
+@item # q
+@kindex @kbd{#q<move>}
+Insert specified string at the beginning of each line in the region
+(@code{vip-quote-region}).
+@item # s
+@kindex @kbd{#s<move>}
+Check spelling of words in the region (@code{spell-region}).
+The function used for spelling is determined from the variable
+@code{vip-spell-function}.
+@vindex @code{vip-spell-function}
+@item *
+@kindex @kbd{*}
+Call last keyboard macro.
+@item m .
+Set mark at point and push old mark off the ring
+@item m<
+@item m>
+Set mark at beginning and end of buffer, respectively.
+@item m,
+Jump to mark and pop mark off the ring. @xref{Mark,,Mark,emacs,The GNU
+Emacs Manual}, for more info.
+@item ] register
+@kindex @kbd{]<a-z>}
+View contents of register
+@item [ textmarker
+@kindex @kbd{[<a-z>}
+View filename and position of textmarker
+@item @@#
+@item @@register
+@item @@!
+@kindex @kbd{@@#}
+@kindex @kbd{@@<a-z>}
+@kindex @kbd{@@!}
+@cindex keyboard macros
+@cindex register execution
+Begin/end keyboard macro. @@register has a different meaning when used after
+a @kbd{@@#}. @xref{Macros and Registers}, for details
+@item []
+@kindex @kbd{[]}
+Go to end of heading.
+@item g <@emph{movement command}>
+Search buffer for text delimited by movement command. The canonical
+example is @kbd{gw} to search for the word under the cursor.
+@xref{Improved Search}, for details.@refill
+@item _
+@kindex @kbd{_}
+Meta key when in Vi state.@xref{Vi State}, for an explanation.
+@item C-g and C-]
+@kindex @kbd{C-g}
+@kindex @kbd{C-]}
+Quit and Abort Recursive edit. These may be necessary on occasion.
+@xref{Vi State}, for a reason.
+@item C-c g
+@kindex @kbd{C-c g}
+Hitting @kbd{C-c} followed by @kbd{g} will display the information on the
+current buffer. This is the same as hitting  @kbd{C-g} in Vi, but, as
+explained above, @kbd{C-g} is needed for other purposes in Emacs.
+@item C-c /
+@kindex @kbd{C-c /}
+Without a prefix argument, this command toggles
+case-sensitive/case-insensitive search modes and plain vanilla/regular
+expression search. With the prefix argument 1, i.e.,
+@kbd{1 C-c /}, this toggles case-sensitivity; with the prefix argument 2,
+toggles plain vanilla search and search using
+regular expressions. @xref{Viper Specials}, for alternative ways to invoke
+this function.
+@cindex vanilla search
+@cindex case-sensitive search
+@cindex case-insensitive search
+@item M-p and M-n
+@kindex @kbd{M-p}
+@kindex @kbd{M-n}
+In the Minibuffer, these commands navigate through the minibuffer
+histories, such as the history of search strings, Ex commands, etc.
+@item C-c M-p and C-c M-n
+@kindex @kbd{C-c M-p}
+@kindex @kbd{C-c M-n}
+@cindex Insertion history
+@cindex Insertion ring
+@cindex Command history
+@cindex Command ring
+In Insert or Replace state, these commands let  the user
+peruse the history of insertion strings used in previous insert or replace
+commands. Try to hit @kbd{C-c M-p} or @kbd{C-c M-n} repeatedly and see what
+happens. @xref{Viper Specials}, for more.
+In Vi state, these commands let the user peruse the history of Vi-style
+destructive commands, such as @kbd{dw}, @kbd{J}, @kbd{a}, etc.
+By repeatedly typing @kbd{C-c M-p} or @kbd{C-c M-n} you will cycle Viper
+through the recent history of Vi commands, displaying the commands one by
+one. Once
+an appropriate command is found, it can be executed by typing `@kbd{.}'.
+Since typing @kbd{C-c M-p} is tedious, it is more convenient to bind an
+appropriate function to a function key on the keyboard and use that key.
+@xref{Viper Specials}, for details.
+@item Ex commands
+@findex  @kbd{:args}
+@findex  @kbd{:n}
+@findex  @kbd{:pwd}
+@findex  @kbd{:pre}
+The commands @kbd{:args}, @kbd{:next}, @kbd{:pre} behave
+differently. @kbd{:pwd} exists to get current directory.
+The commands @kbd{:b} and @kbd{:B} switch buffers around. @xref{File and
+Buffer Handling}, for details.
+There are also the new commands @kbd{:RelatedFile} and
+@kbd{PreviousRelatedFile} (which abbreviate to @kbd{R} and @kbd{P},
+respectively. @xref{Viper Specials}, for details.
+@findex @kbd{:RelatedFile}
+@findex @kbd{:PreviousRelatedFile}
+@end table
+Apart from the new commands, many old commands have been enhanced. Most
+notably, Vi style macros are much more powerful in Viper than in Vi. @xref{Vi
+Macros}, for details.
+@node Useful Packages, ,New Commands, Improvements over Vi
+@section Useful Packages
+Some Emacs packages are mentioned here as an aid to the new Viper user, to
+indicate what Viper is capable of.
+A vast number comes with the standard Emacs distribution, and many more exist
+on the net and on the archives.
+This manual also mentions some Emacs features a new user
+should know about. The details of these are found in the GNU Emacs
+Manual.
+The features first. For details, look up the Emacs Manual.
+@table @samp
+@item Make
+@cindex make
+@cindex compiling
+Makes and Compiles can be done from the editor. Error messages will be
+parsed and you can move to the error lines.
+@item Shell
+@cindex shell
+@cindex interactive shell
+You can talk to Shells from inside the editor. Your entire shell session
+can be treated as a file.
+@item Mail
+@cindex email
+@cindex mail
+Mail can be read from and sent within the editor. Several sophisticated
+packages exist.
+@item Language Sensitive Editing
+Editing modes are written for most computer  languages in existence. By
+controlling indentation, they catch punctuation errors.
+@end table
+The packages, below, represents a drop in the sea of special-purpose
+packages that come with standard distribution of Emacs 19.
+@table @samp
+@item Transparent FTP
+@cindex transparent ftp
+@pindex ange-ftp.el
+@code{ange-ftp.el} can ftp from the editor to files on other machines
+transparent to the user.
+@item RCS Interfaces
+@cindex version maintenance
+@cindex RCS
+@pindex vc.el
+@code{vc.el} for doing RCS commands from inside the editor
+@item Directory Editor
+@cindex dired
+@pindex dired.el
+@code{dired.el} for editing contents of directories and for navigating in
+the file system.
+@item Syntactic Highlighting
+@cindex hilit19
+@pindex hilit19.el
+@cindex font-lock
+@pindex font-lock.el
+@code{hilit19.el} and @code{font-lock.el} for automatic highlighting
+various parts of a buffer
+using different fonts and colors.
+@item Saving Emacs Configuration
+@cindex desktop
+@pindex desktop.el
+@code{desktop.el} for saving/restoring configuration on Emacs exit/startup.
+@item Spell Checker
+@cindex ispell
+@pindex ispell.el
+@code{ispell.el} for spell checking the buffer, words, regions, etc.
+@item File and Buffer Comparison
+@cindex ediff
+@pindex ediff.el
+@code{ediff.el} for finding differences between files and for applying
+patches.
+@end table
+@noindent
+Emacs Lisp archives exist on
+@samp{archive.cis.ohio-state.edu}
+and @samp{wuarchive.wustl.edu}@refill
+@node Customization,Commands,Improvements over Vi,Top
+@chapter Customization
+@cindex customization
+Customization can be done in 2 ways.
+@itemize @bullet
+@item
+@cindex initialization
+@cindex .vip
+Elisp code in a @file{.vip} file in your home directory. Viper
+loads @file{.vip} just before it does the binding for mode
+hooks. This is the recommended method.
+@item
+@cindex .emacs
+Elisp code in your @file{.emacs} file before and after the
+@code{(require 'viper)} line. This method is not recommended, unless you
+are know what you are doing.@refill
+@end itemize
+@noindent
+Emacs customization is done in Emacs Lisp. For the common cases,
+examples are provided that you can use directly.
+@menu
+* Rudimentary Changes::          Simple constant definitions.
+* Keybindings::                  Enabling Emacs Keys, Rebinding keys, etc.
+* Packages that Change Keymaps:: How to deal with such beasts.
+* Viper Specials::               Special Viper commands.
+* Vi Macros::                    How to do Vi style macros.
+@end menu
+@node Rudimentary Changes,Keybindings,Customization,Customization
+@section Rudimentary Changes
+@cindex setting variables
+@cindex variables for customization
+@findex @kbd{:set}
+An easy way to customize Viper is to change the values of constants used in
+Viper.  Here is the list of the constants used in Viper and their default
+values. The corresponding :se command is also indicated. (The symbols
+@code{t} and @code{nil} represent ``true'' and ``false'' in Lisp).
+Viper supports both the abbreviated Vi variable names and their full
+names. Variable completion is done on full names only. @kbd{TAB} and
+@kbd{SPC} complete
+variable names. Typing `=' will complete the name and then will prompt for
+a value, if applicable. For instance, @kbd{:se auSPC} will complete the
+command to @kbd{:set autoindent}; @kbd{:se taSPC} will complete the command
+and prompt further like this: @kbd{:set tabstop = }.
+However, typing @kbd{:se tsSPC} will produce a ``No match'' message
+because @kbd{ts} is an abbreviation for @kbd{tabstop} and Viper supports
+completion on full names only. However, you can still hit @kbd{RET}
+or @kbd{=}, which will complete the command like this: @kbd{:set ts = } and
+Viper will be waiting for you to type a value for the tabstop variable.
+To get the full list of Vi variables, type @kbd{:se SPC TAB}.
+@table @code
+@item vip-auto-indent nil
+@itemx :se ai (:se autoindent)
+@itemx :se gai (:se global-autoindent)
+If @code{t}, enable auto indentation.
+by @kbd{RET}, @kbd{o} or @kbd{O} command.
+@code{vip-auto-indent} is a local variable. To change the value globally, use
+@code{setq-default}. It may be useful for certain major modes to have their
+own values of @code{vip-auto-indent}. This can be achieved by using
+@code{setq} to change the local value of this variable in the hooks to the
+appropriate major modes.
+@kbd{:se ai} changes the value of @code{vip-auto-indent} in the current
+buffer only; @kbd{:se gai} does the same globally.
+@item vip-electric-mode t
+If @code{t}, auto-indentation becomes electric, which means that @kbd{RET},
+@kbd{O}, and @kbd{o} indent cursor according to the current major mode. In
+the future, this variable may control additional electric features.
+This is a local variable: @code{setq} changes the value of this variable
+in the current buffer only. Use @code{setq-default} to change the value in
+all buffers.
+@item vip-case-fold-search nil
+@itemx :se ic (:se ignorecase)
+If @code{t}, search ignores cases.
+This can also be toggled by quickly hitting @kbd{/} twice.
+@item vip-re-search nil
+@itemx :se magic
+If @code{t} then search is reg-exp search, if @code{nil} then vanilla
+search.
+This behavior can also be toggled by quickly hitting @kbd{/} trice.
+@item buffer-read-only
+@itemx :se ro (:se readonly)
+Set current buffer to read only. To change globally put
+@code{(setq-default buffer-read-only t)} in your @file{.emacs} file.
+@item blink-matching-paren t
+@itemx :se sm (:se showmatch)
+Show matching parens by blinking cursor.
+@item tab-width t (default setting via @code{setq-default})
+@itemx :se ts=value (:se tabstop=value)
+@itemx :se gts=value (:se global-tabstop=value)
+@code{tab-width} is a local variable that controls the width of the tab stops.
+To change the value globally, use @code{setq-default}; for local settings,
+use @code{setq}.
+The command @kbd{:se ts}
+sets the tab width in the current
+buffer only; it has no effect on other buffers.
+The command @kbd{:se gts} sets tab width globally,
+for all buffers where the tab is not yet set locally,
+including the new buffers.
+Note that typing @kbd{TAB} normally
+doesn't insert the tab, since this key is usually bound to
+a text-formatting function, @code{indent-for-tab-command} (which facilitates
+programming and document writing). Instead, the tab is inserted via the
+command @code{vip-insert-tab}, which is bound to @kbd{S-tab} (shift + tab).
+On some non-windowing terminals, Shift doesn't modify the @kbd{TAB} key, so
+@kbd{S-tab} behaves as if it were @kbd{TAB}. In such a case, you will have
+to bind @code{vip-insert-tab} to some other convenient key.
+@item vip-shift-width 8
+@itemx :se sw=value  (:se shiftwidth=value)
+The number of columns shifted by @kbd{>} and @kbd{<} commands.
+@item vip-search-wrap-around t
+@itemx :se ws (:se wrapscan)
+If @code{t}, search wraps around the end/beginning of buffer.
+@item vip-tags-file-name "TAGS"
+The name of the file used as the tag table.
+@item vip-re-query-replace nil
+If @code{t}, use reg-exp replace in query replace.
+@item vip-want-ctl-h-help nil
+If @code{t}, @kbd{C-h} is bound to @code{help-command};
+if @code{nil}, it is bound to @code{delete-backward-char}.
+@item vip-vi-style-in-minibuffer t
+If @code{t}, Viper provides a high degree of compatibility with Vi insert mode
+when you type text in the Minibuffer; if @code{nil}, typing in the
+Minibuffer feels like plain Emacs.
+@item vip-no-multiple-ESC t
+If you set this to @code{nil}, you can use @kbd{ESC} as Meta in Vi state.
+Normally, this is not necessary, since graphical displays have separate
+Meta keys (usually on each side of the space bar). On a dumb terminal, Viper
+sets this variable to @code{twice}, which is almost like @code{nil}, except
+that double @kbd{ESC} beeps. This, too, lets ESC to be used as a Meta.
+@item vip-keysequence-delay 140
+Escape sequences separated by this much delay are interpreted as command,
+ignoring the special meaning of ESC in VI. The default is suitable for most
+terminals. However, if your terminal is extremely slow, you
+might want to increase this slightly. You will know if your terminal is
+slow if the ESC key sequences emitted by the arrow keys are interpreted as
+separately typed characters (and thus the arrow keys won't work).
+Making this value too large will slow you down, so exercise restraint.
+@item vip-ex-style-motion t
+Set this to @code{nil}, if you want @kbd{l,h} to cross
+lines, etc. @xref{Movement and Markers}, for more info.
+@item vip-ex-style-editing-in-insert t
+Set this to to @code{nil}, if you want @kbd{ESC} to not move back and
+@kbd{C-h} to not stop
+at the beginning of a line in Insert state.
+@item vip-always t
+Leave it to Viper to decide when a buffer must be brought up in Vi state,
+Insert state, or Emacs state. This heuristics works well in virtually all
+cases.
+This option must be
+set before Viper is loaded or in the @file{.vip} file.
+@item vip-custom-file-name "~/.vip"
+Change this if you want. Must be set in @file{.emacs} (not @file{.vip}!)
+before Viper is loaded. Note that you
+have to set it as a string inside double quotes.
+@item vip-spell-function 'ispell-region
+Function used by the command @kbd{#c<move>} to spell.
+@item ex-nontrivial-find-file-function
+The value of this variable is the function used to find all files that
+match a wildcard. This is usually done when the user types @kbd{:e} and
+specifies a wildcard in the file name (or if the file name contains unusual
+symbols (e.g., a space). Viper provides two functions for this: one for
+Unix-like systems (@code{vip-ex-nontrivial-find-file-unix}) and one for
+DOS, W95, and NT (@code{vip-ex-nontrivial-find-file-ms}). If the default
+function doesn't quite do what you expect or if you prefer to use ``fancy''
+shells, you may have to write your own version of this function and make it
+into the value of @code{ex-nontrivial-find-file-function}.  Use
+@code{vip-ex-nontrivial-find-file-unix} and
+@code{vip-ex-nontrivial-find-file-ms} as examples.
+@vindex @code{ex-nontrivial-find-file-function}.
+@findex @code{vip-ex-nontrivial-find-file-ms}
+@findex @code{vip-ex-nontrivial-find-file-unix}
+@item ex-cycle-other-window t
+If @code{t}, @kbd{:n} and @kbd{:b} will cycle through files in another
+window, if one exists.
+@item ex-cycle-through-non-files nil
+@kbd{:n} does not normally cycle through buffers. Set this to get
+buffers also.
+@item vip-automatic-iso-accents nil
+If @kbd{t}, ISO accents will be turned on in insert/replace Viper states
+and turned off in Vi state. This is useful for editing text in European
+languages. This variable is buffer-local. If used, it should be set in the
+hooks to the appropriate major modes (usually setting it in
+@code{text-mode-hook} is enough).
+@item vip-want-emacs-keys-in-insert
+This is set to @code{nil} for user levels 1 and 2 and to @code{t} for user
+levels 3 and 4. Users who specify level 5 are allowed to set this variable
+as they please (the default for this level is @code{t}). If set to
+@code{nil}, complete Vi compatibility is provided in Insert state. This is
+really not recommended, as this precludes you from using language-specific
+features provided by the major modes.
+@item vip-want-emacs-keys-in-vi
+This is set to @code{nil} for user
+level 1 and to @code{t} for user levels 2--4.
+At level 5, users are allowed to set this variable as they please (the
+default for this level is @code{t}).
+If set to @code{nil}, complete Vi compatibility is provided
+in Vi command state. Setting this to @code{nil} is really a bad idea,
+unless you are a novice, as this precludes the use
+of language-specific features provided by the major modes.
+@item vip-keep-point-on-repeat t
+If @code{t}, point is not moved when the user repeats the previous command
+by typing `.'  This is very useful for doing repeated changes with the
+@kbd{.} key.
+@item vip-repeat-from-history-key 'f12
+Prefix key used to invoke the macros @kbd{f12 1} and @kbd{f12 2} that repeat
+the second-last and the third-last destructive command.
+Both these macros are bound (as Viper macros) to
+@code{vip-repeat-from-history},
+which checks the second key by which it is invoked to see which of the
+previous commands to invoke. Viper binds @kbd{f12 1} and @kbd{f12 2} only,
+but the user can bind more in @file{~/.vip}. @xref{Vi Macros}, for how to do
+this.
+@item vip-keep-point-on-undo nil
+If @code{t}, Viper tries to not move point when undoing commands.
+Instead, it will briefly move the cursor to the place where change has
+taken place. However, if the undone piece of text is not seen in window,
+then point will be moved to the place where the change took place.
+Set it to @code{t} and see if you like it better.
+@item vip-delete-backwards-in-replace nil
+If @code{t}, DEL key will delete characters while moving the cursor backwards.
+If @code{nil}, the cursor will move backwards without deleting anything.
+@item vip-replace-overlay-face 'vip-replace-overlay-face
+On a graphical display, Viper highlights replacement regions instead of
+putting a @samp{$} at the end. This variable controls the so called
+@dfn{face} used to highlight the region.
+By default, @code{vip-replace-overlay-face} underlines the replacement
+on monochrome displays and highlights it with color on  color displays.
+If you know something about Emacs
+faces and don't like how Viper highlights replacement regions, you can change
+this variable to specify a new face name. (Emacs faces are described in the
+Emacs Lisp reference.)
+On a color display, the following customization method is usually
+most effective:
+@example
+(set-face-foreground vip-replace-overlay-face "DarkSlateBlue")
+(set-face-background vip-replace-overlay-face "yellow")
+@end example
+For a complete list of colors available to you, evaluate the
+expression @code{(x-defined-colors)}. (Type it in the buffer @code{*scratch*}
+and then hit the @kbd{C-j} key.
+@item vip-replace-overlay-cursor-color  "Red"
+Cursor color when it is inside the replacement region.
+This has effect only on color displays and only when Emacs runs as an X
+application.
+@item vip-replace-region-end-delimiter "$"
+A string used to mark the end of replacement regions.  It is used only with
+TTYs or if @code{vip-use-replace-region-delimiters} is non-nil.
+@item vip-replace-region-start-delimiter  ""
+A string used to mark the beginning of replacement regions.  It is used
+only with TTYs or if @code{vip-use-replace-region-delimiters} is non-nil.
+@item vip-use-replace-region-delimiters
+If non-nil, Viper will always use @code{vip-replace-region-end-delimiter} and
+@code{vip-replace-region-start-delimiter} to delimit replacement regions,
+even on color displays (where this is unnecessary). By default, this
+variable is non-nil only on TTYs or monochrome displays.
+@item vip-toggle-key "\C-z"
+Specifies the key used to switch from Emacs to Vi and back.
+Must be set in @file{.vip} or prior to loading Viper. This variable can't be
+changed interactively after Viper is loaded.
+@item vip-ESC-key "\e"
+Specifies the key used to escape from Insert/Replace states to Vi.
+Must be set in @file{.vip} or prior to loading Viper. This variable cannot be
+changed interactively after Viper is loaded.
+@item vip-buffer-search-char nil
+Key used for buffer search. @xref{Viper Specials}, for details.
+@item vip-surrounding-word-function 'vip-surrounding-word
+The value of this variable is a function name that is used to determine
+what constitutes a word clicked upon by the mouse. This is used by mouse
+search and insert.
+@item vip-search-face 'vip-search-face
+Variable that controls how search patterns are highlighted when they are
+found.
+@item vip-vi-state-hook nil
+List of parameterless functions to be run just after entering the Vi
+command state.
+@item vip-insert-state-hook nil
+Same for Insert state. This hook is also run after entering Replace state.
+@item vip-replace-state-hook  nil
+List of (parameterless) functions called just after entering Replace state
+(and after all @code{vip-insert-state-hook}).
+@item vip-emacs-state-hook nil
+List of (parameterless) functions called just after switching from Vi state
+to Emacs state.
+@item vip-load-hook nil
+List of (parameterless) functions called just after loading Viper. This is
+the last chance to do customization before Viper is up and running.
+@end table
+@noindent
+You can reset some of these constants in Viper with the Ex command @kbd{:set}
+(when so indicated in the table).  Or you
+can include a line like this in your @file{.vip} file:
+@example
+(setq vip-case-fold-search t)
+@end example
+@vindex @code{vip-auto-indent}
+@vindex @code{vip-electric-mode}
+@vindex @code{vip-case-fold-search}
+@vindex @code{vip-re-search}
+@vindex @code{vip-shift-width}
+@vindex @code{buffer-read-only}
+@vindex @code{vip-search-wrap-around}
+@vindex @code{vip-search-face}
+@vindex @code{vip-tags-file-name}
+@vindex @code{vip-re-query-replace}
+@vindex @code{vip-want-ctl-h-help}
+@vindex @code{vip-vi-style-in-minibuffer}
+@vindex @code{vip-no-multiple-ESC}
+@vindex @code{vip-always}
+@vindex @code{vip-keysequence-delay}
+@vindex @code{vip-ex-style-motion}
+@vindex @code{vip-ex-style-editing-in-insert}
+@vindex @code{vip-custom-file-name}
+@vindex @code{vip-spell-function}
+@vindex @code{ex-cycle-other-window}
+@vindex @code{ex-cycle-through-non-files}
+@vindex @code{vip-automatic-iso-accents}
+@vindex @code{vip-want-emacs-keys-in-insert}
+@vindex @code{vip-want-emacs-keys-in-vi}
+@vindex @code{vip-keep-point-on-repeat}
+@vindex @code{vip-keep-point-on-undo}
+@vindex @code{vip-delete-backwards-in-replace}
+@vindex @code{vip-replace-overlay-face}
+@vindex @code{vip-replace-region-end-symbol}
+@vindex @code{vip-replace-region-start-symbol}
+@vindex @code{vip-toggle-key}
+@vindex @code{vip-ESC-key}
+@vindex @code{vip-buffer-search-char}
+@vindex @code{vip-surrounding-word-function}
+@vindex @code{vip-vi-state-hook}
+@vindex @code{vip-insert-state-hook}
+@vindex @code{vip-replace-state-hook}
+@vindex @code{vip-emacs-state-hook}
+@node Keybindings, Packages that Change Keymaps, Rudimentary Changes,Customization
+@section Keybindings
+@cindex keybindings
+@cindex keymaps
+Viper lets you define hot keys, i.e., you can associate keyboard keys
+such as F1, Help, PgDn, etc., with Emacs Lisp functions (that may already
+exist or that you will write). Each key has a "preferred form" in
+Emacs. For instance, the Up key's preferred form is [up], the Help key's
+preferred form is [help], and the Undo key has the preferred form [f14].
+You can find out the preferred form of a key by typing @kbd{M-x
+describe-key-briefly} and then typing the key you want to know about.
+Under X Windows, every keyboard key emits its preferred form, so you can
+just type
+@lisp
+(global-set-key [f11] 'calendar)                        ; L1, Stop
+(global-set-key [f14] 'undo)                            ; L4, Undo
+@end lisp
+@noindent
+to bind L1 so it will invoke the Emacs Calendar and to bind L4 so it will
+undo changes.
+However, on a dumb terminal or in an Xterm window, even the standard arrow
+keys may
+not emit the right signals for Emacs to understand. To let Emacs know about
+those keys, you will have to find out which key sequences they emit
+by typing @kbd{C-q} and then the key (you should switch to Emacs state
+first). Then you can bind those sequences to their preferred forms using
+@code{function-key-map} as follows:
+@lisp
+(cond ((string= (getenv "TERM") "xterm")
+(define-key function-key-map "\e[192z" [f11])    ; L1
+(define-key function-key-map "\e[195z" [f14])    ; L4, Undo
+@end lisp
+The above illustrates how to do this for Xterm. On VT100, you would have to
+replace "xterm" with "vt100" and also change the key sequences (the same
+key may emit different sequences on different types of terminals).
+The above keys are global, so they are overwritten by the local maps
+defined by the major modes and by Viper itself. Therefore, if you wish to
+change a binding set by a major mode or by Viper, read this.
+Viper users who wish to specify their own key bindings should be concerned
+only with the following three keymaps:
+@code{vip-vi-global-user-map} for Vi state commands,
+@code{vip-insert-global-user-map} for Insert state commands,
+and @code{vip-emacs-global-user-map} for Emacs state commands (note:
+customized bindings for Emacs state made to @code{vip-emacs-global-user-map}
+are @emph{not} inherited by Insert state).
+For more information on Viper keymaps, see the header of the file
+@file{viper.el}.
+If you wish to change a Viper binding, you can use the
+@code{define-key} command, to modify @code{vip-vi-global-user-map},
+@code{vip-insert-global-user-map}, and @code{vip-emacs-global-user-map}, as
+explained below. Each of these key maps affects the corresponding Viper state.
+The keymap @code{vip-vi-global-user-map} also affects Viper's Replace state.
+@noindent
+If you want to
+bind a key, say @kbd{C-v}, to the function that scrolls
+page down and to make @kbd{0} display information on the current buffer,
+putting this in @file{.vip} will do the trick in Vi state:
+@example
+(define-key vip-vi-global-user-map "\C-v" 'scroll-down)
+@end example
+@noindent
+To set a key globally,
+@example
+(define-key vip-emacs-global-user-map "\C-c m" 'smail)
+(define-key vip-vi-global-user-map "0" 'vip-info-on-file)
+@end example
+@noindent
+Note, however, that this binding may be overwritten by other keymaps, since
+the global keymap has the lowest priority.
+To make sure that nothing will override a binding in Emacs state, you
+can write this:
+@example
+(define-key vip-emacs-global-user-map "\C-c m" 'smail)
+@end example
+@noindent
+To customize the binding for @kbd{C-h} in Insert state:
+@example
+(define-key vip-insert-global-user-map "\C-h" 'my-del-backwards-function)
+@end example
+@noindent
+Each Emacs command key calls some lisp function. If you have enabled the
+Help, (@xref{Rudimentary Changes}) @kbd{C-h k} will show you the function
+for each specific key; @kbd{C-h b} will show all bindings, and @kbd{C-h m}
+will provide information on the major mode in effect. If Help is not
+enabled, you can still get help in Vi state by prefixing the above commands
+with @kbd{\}, e.g., @kbd{\ C-h k} (or you can use the Help menu in the
+menu bar, if Emacs runs under X Windows).
+Viper users can also change bindings on a per major mode basis.  As with
+global bindings, this can be done separately for each of the three main Viper
+states.  To this end, Viper provides the function
+@code{vip-modify-major-mode}.
+@findex @code{vip-modify-major-mode}
+To modify keys in Emacs state for @code{my-favorite-major-mode}, the user
+needs to create a sparse keymap, say, @code{my-fancy-map}, bind whatever
+keys necessary in that keymap, and put
+@example
+(vip-modify-major-mode 'dired-mode 'emacs-state my-fancy-map)
+@end example
+@noindent
+in @file{~/.vip}. To do the same in Vi and Insert states, one should use
+@code{vi-state} and @code{insert-state}. Changes in Insert state are also
+in effect in Replace state.  For instance, suppose that the user wants to
+use @kbd{dd} in Vi state under Dired mode to delete files, @kbd{u} to unmark
+files, etc. The following code in @file{~/.vip} will then do the job:
+@example
+(setq my-dired-modifier-map (make-sparse-keymap))
+(define-key my-dired-modifier-map "dd" 'dired-flag-file-deletion)
+(define-key my-dired-modifier-map "u" 'dired-unmark)
+(vip-modify-major-mode 'dired-mode 'vi-state my-dired-modifier-map)
+@end example
+A Vi purist may want to modify Emacs state under Dired mode so that
+@kbd{k}, @kbd{l}, etc., will move around in directory buffers, as in
+Vi. Although this is not recommended, as these keys are bound to useful
+Dired functions, the trick can be accomplished via the following code:
+@example
+(setq my-dired-vi-purist-map (make-sparse-keymap))
+(define-key my-dired-vi-purist-map "k" 'vip-previous-line)
+(define-key my-dired-vi-purist-map "l" 'vip-forward-char)
+(vip-modify-major-mode 'dired-mode 'emacs-state my-dired-vi-purist-map)
+@end example
+Similar effect can be achieved by defining Vi keyboard macros using the
+Ex commands @kbd{:map} and @kbd{:map!}. The difference is that multi-key
+Vi macros do not override the keys they are bound to, unless these keys are
+typed in quick succession. So, with macros, one can use the normal keys
+alongside with the macros. If per-mode modifications are needed, the user
+can try both ways and see which one is more convenient.
+@findex @kbd{:map}
+@xref{Vi Macros}, for details.
+Note: in major modes that come up in @emph{Emacs state} by default, the
+aforesaid modifications may not take place immediately (but only after the
+buffer switches to some other Viper state and then back to Emacs state).  To
+avoid this, one should add @code{vip-change-state-to-emacs} to an
+appropriate hook of that major mode. (Check the function
+@code{vip-set-hooks} in @file{viper.el} for examples.)  However, if you
+have set @code{vip-always} to @code{t}, chances are that you won't need to
+perform the above procedure, because Viper will take care of most useful
+defaults.
+Finally, Viper has a facility that lets the user define per-buffer
+bindings, i.e., bindings that are in effect in some specific buffers
+only. Unlike per-mode bindings described above, per-buffer bindings can be
+defined based on considerations other than the major mode.  This is done
+via the function @code{vip-add-local-keys}, which lets one specify bindings
+that should be in effect in the current buffer only and for a specific Viper
+state. For instance,
+@lisp
+(vip-add-local-keys 'vi-state '(("ZZ" . TeX-command-master)
+("ZQ" . vip-save-kill-buffer)))
+@end lisp
+@noindent
+redefines @kbd{ZZ} to invoke @code{TeX-command-master} in @code{vi-state}
+and @kbd{ZQ} to save-then-kill the current buffer. These bindings take
+effect only in the buffer where this command is executed. The typical use
+of this function is to execute the above expression from within a function
+that is included in a hook to some major mode. For instance, the above
+expression
+could be called from a function, @code{my-tex-init}, which may be added to
+@code{tex-mode-hook} as follows:
+@lisp
+(add-hook 'tex-mode-hook 'my-tex-init)
+@end lisp
+@noindent
+When TeX mode starts, the hook is executed and the above Lisp expression is
+evaluated. Then, the bindings for @kbd{ZZ} and @kbd{ZQ} are changed in Vi
+command mode for all buffers in TeX mode.
+Another useful application is to bind @kbd{ZZ} to @code{send-mail}
+in the Mail mode buffers (the specifics of this depend on which mail
+package you are using, @code{rmail}, @code{mh-e}, @code{vm}, etc.
+For instance, here is how to do this for @code{mh-e}, the Emacs interface
+to MH:
+@lisp
+(defun mh-add-vi-keys ()
+"Set up ZZ for MH-e and XMH."
+(vip-add-local-keys 'vi-state '(("ZZ" . mh-send-letter))))
+(add-hook 'mh-letter-mode-hook 'mh-add-vi-keys)
+@end lisp
+You can also use @code{vip-add-local-keys} to set per buffer
+bindings in Insert state and Emacs state by passing as a parameter the
+symbols @code{'insert-state} and @code{'emacs-state}, respectively.
+As with global bindings, customized local bindings done to Emacs state
+are not inherited by Insert state.
+On rare occasions, local keys may be added by mistake. Usually this is done
+indirectly, by invoking a major mode that adds local keys (e.g.,
+@code{shell-mode} redefines @kbd{RET}). In such a case, exiting the wrong
+major mode won't rid you from unwanted local keys, since these keys are
+local to Viper state and the current buffer, not to the major mode.
+In such situations, the remedy is to type @kbd{M-x vip-zap-local-keys}.
+So much about Viper-specific bindings.
+@xref{Customization,,Customization,emacs,The GNU Emacs
+Manual}, and the Emacs quick reference card for the general info on key
+bindings in Emacs.
+@vindex @code{function-key-map}
+@vindex @code{vip-vi-global-user-map}
+@vindex @code{vip-insert-global-user-map}
+@vindex @code{vip-emacs-global-user-map}
+@findex @code{vip-add-local-keys}
+@findex @code{vip-zap-local-keys}
+@node Packages that Change Keymaps,Viper Specials,Keybindings,Customization
+@subsection Packages that Change Keymaps
+@cindex C-c and Viper
+@cindex Viper and C-c
+Viper is designed to coexist with all major and minor modes of Emacs. This
+means that bindings set by those modes are generally available with Viper
+(unless you explicitly prohibit them by setting
+@code{vip-want-emacs-keys-in-vi} and @code{vip-want-emacs-keys-in-insert} to
+@code{nil}).
+If @code{vip-always} is set to @code{t}, Viper will try to bring each buffer
+in the a Viper state that is most appropriate for that buffer.
+Usually, this would be the Vi state, but sometimes it could be the Insert
+state or the Emacs state.
+Some major mode bindings will necessarily be overwritten by Viper. Indeed, in
+Vi state, most of the 1-character keys are used for Vi-style editing.  This
+usually causes no problems because most packages designed for editing files
+typically do not bind such keys. Instead, they use key sequences that start
+with @kbd{C-x} and @kbd{C-c}. This is why it was so important for us to
+free up @kbd{C-x} and @kbd{C-c}.
+It is common for language-specific major modes to bind @kbd{TAB} and
+@kbd{LFD} (the line feed) keys to various formatting functions. This is
+extremely useful, but may require some getting used to for a Vi user. If you
+decide that this feature is not for you, you can re-bind these keys as
+explained earlier (@xref{Customization}).
+Binding for @kbd{TAB} is one of the most unusual aspects of Viper for many
+novice users.  In Emacs, @kbd{TAB} is used to format text and programs, and
+is extremely useful. For instance, hitting @kbd{TAB} causes the current
+line to be re-indented in accordance with the context.  In programming,
+this is very important, since improper automatic indentation would
+immediately alert the programmer to a possible error. For instance, if a
+@kbd{)} or a @kbd{"} is missing somewhere above the current
+line, @kbd{TAB} is likely to mis-indent the line.
+For this reason, Viper doesn't change the standard Emacs binding of
+@kbd{TAB}, thereby sacrificing Vi compatibility
+(except for users at level 1). Instead, in Viper, the key
+@kbd{S-tab} (shift+ tab) is chosen to emulate Vi's @kbd{TAB}.
+We should note that on some non-windowing terminals, Shift doesn't modify
+the @kbd{TAB} key, so @kbd{S-tab} behaves as if it were @kbd{TAB}. In such
+a case, you will have to bind @code{vip-insert-tab} to some other
+convenient key.
+Some packages, notably Dired, Gnus, Info, etc., attach special meaning
+to common keys like @kbd{SPC}, @kbd{x}, @kbd{d}, @kbd{v}, and others. This
+means that Vi command state is inappropriate for working with these
+packages. Fortunately, these modes operate on read-only buffers and are
+designed not for editing files, but for special-purpose browsing, reading
+news, mail, etc., and Vi commands are meaningless in these situations. For
+this reason, Viper doesn't force Vi state on such major modes.  Rather, it
+brings them in Emacs state. You can switch to Vi state by typing @kbd{C-z}
+if, for instance, you want to do Vi-style search in a buffer (although,
+usually, incremental search, which is bound to @kbd{C-s}, is sufficient in
+these situations). But you should then switch back to Emacs state if you
+plan to continue using these major modes productively. You can also switch
+to Vi temporarily, to execute one 1-character command. This is done by
+typing @kbd{M-C-z} (or @kbd{ESC C-z}).
+This facility cannot execute several complex Vi commands, such as @kbd{dw},
+@kbd{de}, etc.
+It is also possible to harness some major modes, even though they may bind
+common keys to specialized commands. Harnessing can make sense for modes
+that bind only a small number of common keys.  For instance, if
+@code{vip-always} is set to @code{t} in your @file{~/.vip} file, Viper will
+harness the Shell mode by changing the bindings for @kbd{C-m} and @kbd{C-d}
+using @code{vip-add-local-keys} described in section on customization
+(@xref{Customization}). In general, there is no single recipe for
+harnessing modes. It can be as simple as adding the function
+@code{viper-mode} to a hook associated with the mode, or it can be more
+complex, as in the case of Shell mode and Emerge. Take a look at
+@code{vip-set-hooks} function for some examples.
+Conversely, it may be the case that most of the major modes harnessed
+by @code{vip-set-hooks} function fit your working style, except one or two
+cases. In this case, you may still be able to set @code{vip-always} to
+@code{t} and then remove a hook that forces Vi command state. For instance,
+to unharness @code{lisp-interaction-mode}, you can put the following line
+in your @file{.emacs} (not @code{.vip}!) file after @code{(require 'viper)}:
+@lisp
+(remove-hook 'lisp-interaction-mode-hook 'viper-mode)
+@end lisp
+In some rare cases, some minor modes may override certain essential
+bindings in Vi command state.  This is not really catastrophic because this
+may happen only in the beginning, when the minor mode kicks in. Typing
+@code{M-x viper-mode} will correct the situation.  Viper knows about
+several such minor modes and takes care of them, so that the above trick
+is usually not necessary.  If you find that some minor mode, e.g.,
+@code{nasty-mode.el} interferes with Viper, putting the following in
+@file{.vip} should fix the problem:
+@lisp
+(vip-harness-minor-mode "nasty-mode")
+@end lisp
+@noindent
+The argument to @code{vip-harness-minor-mode} is the name of the file for the
+offending minor mode with the suffixes @file{.el} and @file{.elc} removed.
+It may be tricky, however, to find out which minor mode is at fault. The
+only guidance here is to look into the file that defines the minor mode you
+are suspecting, say @code{nasty-mode.el}, and see if it has a variable
+called @code{nasty-mode-map}. Then check if there is a statement of the form
+@lisp
+(define-key nasty-mode-map key function)
+@end lisp
+@noindent
+that binds the misbehaving
+keys. If so, use the above line to harness @code{nasty-mode}. If your
+suspicion is wrong, no harm is done if you harness a minor mode that
+doesn't need to be harnessed.
+@vindex @code{vip-want-emacs-keys-in-vi}
+@vindex @code{vip-want-emacs-keys-in-insert}
+@vindex @code{vip-always}
+@findex @code{vip-set-hooks}
+@findex @code{viper-mode}
+@findex @code{vip-harness-minor-mode}
+@findex @code{remove-hook}
+@findex @code{add-hook}
+@node Viper Specials,Vi Macros,Packages that Change Keymaps,Customization
+@section Viper Specials
+Viper extends Vi with a number of useful features. This includes various
+search functions, histories of search strings, Ex commands, insertions, and
+Vi's destructive commands. In addition, Viper supports file name completion
+and history, completion of Ex commands and variables, and many other
+features. Some of these features are explained in detail elsewhere in this
+document. Other features are explained here.
+@table @code
+@item (vip-buffer-search-enable)
+@item vip-buffer-search-char nil
+Enable buffer search. Explicit call to @code{vip-buffer-search-enable}
+sets @code{vip-buffer-search-char} to @kbd{g}. Alternatively, the user can
+set @code{vip-buffer-search-char} in @file{.vip} to a key sequence
+to be used for buffer search. There is no need to call
+@code{vip-buffer-search-enable} in that case.
+@findex @code{vip-buffer-search-enable}
+@vindex @code{vip-buffer-search-char}
+@item vip-toggle-search-style
+This function, bound to @kbd{C-c /}, lets one toggle case-sensitive and
+case-insensitive search, and also switch between plain vanilla search and
+search via regular expressions. Without the prefix argument, the user is
+asked which mode to toggle. With prefix argument 1, this toggles
+case-sensitivity. With prefix argument 2, regular expression/vanilla search
+will be toggled.
+However, we found that the most convenient way to toggle
+these options is to bind a Vi macro to
+bind @kbd{//} to toggles case sensitivity and to @kbd{///} to toggles
+vanilla search. Thus, quickly hitting @kbd{/} twice will switch Viper from
+case sensitive search to case-insensitive. Repeating this once again will
+restore the original state. Likewise, quickly hitting @kbd{/} three times
+will switch you from vanilla-style search to search via regular expressions.
+If you hit something other than @kbd{/} after the first @kbd{/} or if the
+second @kbd{/} doesn't follow quickly enough, then Viper will issue the
+usual prompt @kbd{/} and will wait for input, as usual in Vi.
+If you don't like this behavior, you can ``unrecord'' these macros in your
+@file{~/.vip} file. For instance, if u don't like the above feature, put
+this in @file{~/.vip}:
+@example
+(vip-unrecord-kbd-macro "//" 'vi-state)
+(vip-unrecord-kbd-macro "///" 'vi-state)
+@end example
+@findex @code{vip-unrecord-kbd-macro}
+@xref{Vi Macros}, for more information on Vi macros.
+@item vip-heading-start
+@item vip-heading-end
+@cindex headings
+@cindex sections
+@cindex paragraphs
+@cindex sentences
+Regular Expressions for @kbd{[[} and @kbd{]]}. Note that Emacs defines
+Regexps for paragraphs and sentences. @xref{Paragraphs,,Paragraphs and
+Sentences,emacs,The GNU Emacs Manual}, for details.
+@item M-x vip-set-expert-level
+@findex @code{vip-set-expert-level}
+Change your user level interactively.
+@item vip-smart-suffix-list  '("" "tex" "c" "cc" "el" "p")
+@vindex @code{vip-smart-suffix-list}
+Viper supports Emacs-style file completion when it prompts the user for a
+file name. However, in many cases, the same directory may contain files
+with identical prefix but different suffixes, e.g., prog.c, prog.o,
+paper.tex, paper.dvi. In such cases, completion will stop at the `.'.
+If the above variable is a list of strings representing suffixes, Viper will
+try these suffixes
+in the order listed and will check if the corresponding file exists.
+For instance, if completion stopped at `paper.' and the user typed RET,
+then Viper will check if the files `paper.', `paper.tex', `paper.c', etc., exist.
+It will take the first such file. If no file exists, Viper will give a chance
+to complete the file name by typing the appropriate suffix. If `paper.' was
+the intended file name, hitting return will accept it.
+To turn this feature off, set the above variable to @code{nil}.
+@item vip-insertion-ring-size  14
+@vindex @code{vip-insertion-ring-size}
+@cindex Insertion ring
+Viper remembers what was previously inserted in Insert and Replace states.
+Several such recent insertions are kept in a special ring of strings of size
+@code{vip-insertion-ring-size}.
+If you enter Insert or Replace state you can reinsert strings from this
+ring by typing @kbd{C-c M-p} or @kbd{C-c M-n}. The former will search the
+ring in
+the direction of older insertions, and the latter will search in
+the direction of newer insertions. Hitting @kbd{C-c M-p} or @kbd{C-c M-n}
+in succession
+will undo the previous insertion from the ring and insert the next item on
+the ring. If a larger ring size is needed, change the value of the above
+variable in the @file{~/.vip} file.
+Since typing these sequences of keys may be tedious, it is suggested that the
+user should bind a function key, such as @kbd{f31}, as follows:
+@example
+(define-key vip-insert-global-user-map [f31]
+'vip-insert-prev-from-insertion-ring)
+@end example
+This binds @kbd{f31} (which is usually @kbd{R11} on a Sun workstation)
+to the function that inserts the previous string in the insertion history.
+To rotate the history in the opposite
+direction, you can either bind an unused key to
+@code{vip-insert-next-from-insertion-ring} or hit any digit (1 to 9) then
+@kbd{f31}.
+One should not bind the above functions to @kbd{M-p} or @kbd{M-n}, since
+this will interfere with the Minibuffer histories and, possibly, other
+major modes.
+@item vip-command-ring-size  14
+@vindex @code{vip-command-ring-size}
+@cindex Destructive command ring
+@cindex Destructive command history
+Viper keeps track of the recent history of destructive
+commands, such as @kbd{dw}, @kbd{i}, etc.
+In Vi state,
+the most recent command can be re-executed by hitting `@kbd{.}', as in Vi.
+However, repeated typing @kbd{C-c M-p} will cause Viper to show the
+previous destructive commands in the minibuffer. Subsequent hitting `@kbd{.}'
+will execute the command that was displayed last.
+The key @kbd{C-c M-n} will cycle through the command history in the
+opposite direction.
+Since typing @kbd{C-c M-p} may be tedious, it is more convenient to bind an
+appropriate function to an unused function key on the keyboard and use that
+key. For instance, the following
+@example
+(define-key vip-vi-global-user-map [f31]
+'vip-prev-destructive-command)
+@end example
+binds the key @kbd{f31} (which is usually @kbd{R11} on a Sun workstation)
+to the function that searches the command history in the direction of older
+commands. To search in the opposite
+direction, you can either bind an unused key to
+@code{vip-next-destructive-command} or hit any digit (1 to 9) then @kbd{f31}.
+One should not bind the above functions to @kbd{M-p} or @kbd{M-n}, since
+this will interfere with the Minibuffer histories and, possibly, other
+major modes.
+@item vip-minibuffer-vi-face  'vip-minibuffer-vi-face
+@item vip-minibuffer-insert-face  'vip-minibuffer-insert-face
+@item vip-minibuffer-emacs-face  'vip-minibuffer-emacs-face
+These faces control the appearance of the minibuffer text in the
+corresponding Viper states. For heavy-duty customization, consult
+the Lisp Reference to Emacs. You can also take a look how these faces are
+defined in @file{viper.el}.
+However, on a color workstation, the following method usually suffices:
+@example
+(set-face-foreground vip-minibuffer-vi-face "blue")
+(set-face-background vip-minibuffer-emacs-face "orchid")
+@end example
+This will make a blue foreground in the Minibuffer when it is in Vi
+state; its background will turn to orchid when it switches to Emacs state.
+Note that only the text you type in is affected by the above faces.
+Prompts and Minibuffer messages are not affected.
+Purists who do not like adornments in the minibuffer can always zap them by
+putting
+@example
+(copy-face 'default 'vip-minibuffer-vi-face)
+(copy-face 'default 'vip-minibuffer-insert-face)
+(copy-face 'default 'vip-minibuffer-emacs-face)
+@end example
+in the @file{~/.vip} file. However, in that case, the user will not have any
+indication of the current Viper state in the minibuffer. (This is important
+if the user accidentally switches to another Viper state by typing @kbd{ESC} or
+@kbd{C-z}.
+@end table
+@cindex Multifile documents and programs
+Viper provides some support for multi-file documents and programs.
+If a document consists of several files we can designate one of them as a
+master and put the following at the end of that file:
+@lisp
+;;; Local Variables:
+;;; eval: (vip-setup-master-buffer "file1" "file2" "file3" "file5" "file5")
+;;; End:
+@end lisp
+@noindent
+where @code{file1} to @code{file5} are names of files related to the master
+file. Next time, when the master file is visited, the command
+@code{vip-setup-master-buffer} will be evaluated and the above files will
+be associated with the master file. Then, the new Ex command
+@kbd{:RelatedFile} (abbr. @kbd{:R}) will display files 1 to 5 one after
+another, so you can edit them. If a file is not in any Emacs buffer, it
+will be visited.  The command @kbd{PreviousRelatedFile} (abbr., @kbd{:P})
+goes through the file list in the opposite direction.
+@findex @kbd{:RelatedFile}
+@findex @kbd{:PreviousRelatedFile}
+These commands are akin to @kbd{:n} and @kbd{:N}, but they allow the user to
+focus on relevant files only.
+Note that only the master file needs to have the aforementioned block of
+commands. Also, ";;;" above can be replaced by some other
+markers. Semicolon is good for Lisp programs, since it is considered a
+comment designator there. For LaTeX, this could be "%%%", and for C the
+above block should be commented out.
+Even though these commands are sometimes useful, they are no substitute for
+the powerful @emph{tag table} facility of Emacs. Viper's @kbd{:tag} command
+in a primitive interface to Emacs tags. @xref{Tags,Tags,Tags,emacs,
+The Gnu Emacs Manual}, for more information on tags.
+The following two commands are normally bound to a mouse click and are part
+of Viper. They work only if Emacs runs as an application under X
+Windows (or under some other window system for which a port of GNU Emacs 19
+is available). Clicking the mouse when Emacs is invoked in an Xterm window
+(using @code{emacs -nw}) will do no good.
+@table @code
+@cindex mouse
+@item M-S-mouse-1 (Emacs)
+@item meta shift button1up (XEmacs)
+Holding Meta and Shift while clicking mouse button 1
+will initiate search for a region under the
+mouse pointer (defined below).  This command can take a prefix argument,
+which indicates the occurrence of the pattern to search for.
+Note: Viper binds this mouse action only if it is not already bound to
+something else. If you want to use this feature and @kbd{M-S-mouse-1}
+is already used for something else, you can rebind mouse-search as, for
+example, in the following example:
+@lisp
+(global-set-key [M-mouse-1] 'vip-mouse-click-search-word)
+(global-set-key [M-down-mouse-1] 'vip-mouse-catch-frame-switch)
+@end lisp
+This would bind mouse search to the action invoked by pressing the
+Meta key and clicking mouse button 1. Note: if
+@code{vip-mouse-click-search-word} is bound to an action, then
+@code{vip-mouse-catch-frame-switch} must be bound to a down-action, as
+shown in the above example.
+In XEmacs, you can change bindings as follows:
+@lisp
+(global-set-key [(meta control button1up)]
+'vip-mouse-click-search-word)
+(global-set-key [(meta control button1)]
+'vip-mouse-catch-frame-switch)
+@end lisp
+if, say, you prefer to hold both meta and control while clicking.
+Like in Emacs, there are special rules for binding these functions: the
+first must be bound to a button-up event while the second must be bound to
+a button-event (which is XEmacs' equivalent of a down-mouse event).  Also,
+in Emacs, the double-click and triple-click actions for the same button
+(@code{double-S-mouse-1}, etc., if the above default binding is used)
+should not be bound (or it should be bound to the same function,
+@code{vip-mouse-click-search-word}).
+The region that is chosen as a pattern to search for is determined as
+follows. If search is invoked via a single click, Viper chooses the region
+that lies between the beginning of the ``word'' under the pointer (``word''
+is understood in Vi sense) and the end of that word.  The only difference
+with Vi's words is that in Lisp major modes `-' is considered an
+alphanumeric symbol. This is done for the convenience of working with Lisp
+symbols, which often have an `-' in them.  Also, if you click on a
+non-alphanumeric character that is not a word separator (in Vi sense) then
+this character will also be considered alphanumeric, provided that it is
+adjacent (from either side) to an alphanumeric character.  This useful
+feature gives added control over the patterns selected by the mouse click.
+On a double-click, the region is determined by the beginning of the current
+Vi's ``Word'' (i.e., the largest non-separator chunk of text) and the End
+of that ``Word'' (as determined by the @kbd{E} command).
+On a triple-click, the region consists of the entire line where the click
+occurred with all leading and trailing spaces and tabs removed.
+@item M-S-mouse-2 (Emacs)
+@item meta shift button2up (XEmacs)
+Holding Meta and Shift while clicking mouse button 2
+will insert the region surrounding the
+mouse pointer.  The rules defining this region are the same as for
+mouse-search.  This command takes an optional prefix argument, which
+indicates how many such regions to snarf from the buffer and insert.  (In
+case of a triple-click, the prefix argument is ignored.)
+Note: Viper binds this mouse action only if it not already bound to
+something else. If you want to use this feature and @kbd{S-mouse-2}
+is already used for something else, you can rebind mouse-insert as follows:
+@lisp
+(global-set-key [M-mouse-2] 'vip-mouse-click-insert-word)
+(global-set-key [M-down-mouse-2] 'vip-mouse-catch-frame-switch)
+@end lisp
+In XEmacs, you can change the bindings as follows:
+@lisp
+(global-set-key [(meta control button2up)]
+'vip-mouse-click-insert-word)
+(global-set-key [(meta control button2)]
+'vip-mouse-catch-frame-switch)
+@end lisp
+@item vip-multiclick-timeout
+This variable controls the rate at which double-clicking must occur for the
+purpose of mouse search and mouse insert. By default, this is set to
+@code{double-click-time} in Emacs and to
+@code{mouse-track-multi-click-time} milliseconds in XEmacs.
+@end table
+@kindex @kbd{S-mouse-1}
+@kindex @kbd{S-mouse-2}
+@kindex @kbd{meta shift button1up}
+@kindex @kbd{meta shift button2up}
+@vindex @code{vip-multiclick-timeout}
+@findex @code{vip-mouse-click-insert-word}
+@findex @code{vip-mouse-click-search-word}
+Note: The above functions search and insert in the selected window of
+the latest active frame. This means that you can click in another window or
+another frame and have search or insertion done in the frame and window you
+just left.  This lets one use these functions in a multi-frame
+configuration.  However, this may require some getting used to. For
+instance, if you are typing in a frame, A, and then move the mouse to frame
+B and click to invoke mouse search, search (or insertion) will be performed
+in frame A. To perform search/insertion in frame B, you will first have to
+shift focus there, which doesn't happen until you type a character or
+perform some other action in frame B---mouse search doesn't shift focus (in
+XEmacs, to shift focus to frame B, you will have to select this frame with
+a mouse, by clicking.
+If you decide that you don't like the above feature and always want
+search/insertion be performed in the frame where the click occurs, don't
+bind (and unbind, if necessary) @code{vip-mouse-catch-frame-switch} from
+the mouse event it is bound to.
+Mouse search is integrated with Vi-style search, so you can
+repeat it with @kbd{n} and @kbd{N}. It should be also noted that, while
+case-sensitivity of search in Viper is controlled by the variable
+@code{vip-case-fold-search}, the case of mouse search is
+controlled by the Emacs variable @code{case-fold-search}, which may be set
+differently from @code{vip-case-fold-search}. Therefore, case-sensitivity
+of mouse search may be different from that of the usual Vi-style search.
+Finally, if the way Viper determines the word to be searched for or to be
+inserted is not what you want, there is a variable,
+@code{vip-surrounding-word-function}, which can be changed to indicate
+another function for snarfing words out of the buffer. The catch is that
+you will then have to write such a function and make it known to your
+Emacs. The function @code{vip-surrounding-word} in @file{viper.el} can be
+used as a guiding example.
+@node Vi Macros, ,Viper Specials,Customization
+@section Vi Macros
+@cindex Vi macros
+Viper supports much enhanced Vi-style macros and also facilitates the use
+of Emacs-style macros.  To define a temporary macro, it is generally more
+convenient to use Emacs keyboard macro facility. Emacs keyboard macros are
+usually defined anonymously, and the latest macro can be executed by typing
+@kbd{C-x e} (or @kbd{*}, if Viper is in Vi state). If you need to use several
+temporary macros, Viper lets you save them to a
+register (a lowercase letter); such macros can then be executed by typing
+@kbd{@@a} in Vi state (if a macro was previously saved in register
+@kbd{a}).
+@xref{Macros and Registers}, for details.
+If, however, you need to use a macro regularly, it must be given a
+permanent name and saved. Emacs manual explains how to do this, but
+invocation of named Emacs macros is quite different from Vi's. First,
+invocation of permanent Emacs macros takes time because of the extra keys.
+Second, binding such macros to function keys, for
+fast access, hogs valuable real estate on the keyboard.
+Vi-style macros are better in that respect, since Vi lets the user overload
+the meaning of key sequences: keys typed in fast succession are treated
+specially, if this key sequence is bound to a macro.
+Viper provides keyboard macros through the usual Ex commands, @kbd{:map} and
+@kbd{:map!}. Vi-style macros are much more powerful in Viper than
+they are in the original Vi and in other emulators. This is because Viper
+implements an enhanced vi-style
+interface to the powerful Emacs keyboard macro facility.
+First, any Emacs
+command can be executed while defining a macro, not just the Vi
+commands. In particular, the user can invoke Emacs commands via @kbd{M-x
+command-name} or by pressing various function keys on the keyboard. One
+can even use the mouse, although this is usually not useful and is not
+recommended (and macros defined with the use of the mouse cannot be saved in
+command history and in the startup file, for future use).
+Macros defined by mixing Vi and Emacs commands are represented as
+vectors. So, don't be confused when you see one (usually through the
+history of Ex commands). For instance, if @kbd{gg} is defined by typing
+@kbd{l}, the up-arrow key and @kbd{M-x next-line}, its definition will look
+as follows in Emacs (in XEmacs, it looks slightly different, see below):
+@example
+[l up (meta x) n e x t - l i n e return]
+@end example
+Second, Viper macros are defined in a WYSIWYG style. This means that
+commands are executed as you type them, so you can see precisely what is
+being defined.  Third, macros can be bound to arbitrary sequences of keys,
+not just to printable keys. For instance, one can define a macro that will
+be invoked by hitting @kbd{f3} then @kbd{f2} function keys. (The keys
+@kbd{delete} and @kbd{backspace} are excluded; also, a macro invocation
+sequence can't start with ESC. Some other keys, such as @kbd{f1} and
+@kbd{help}, can't be bound to macros under Emacs (not XEmacs), since they
+are bound in @code{key-translation-map}, which overrides any other binding
+the user gives to keys. In general, keys that have a binding in
+@code{key-translation-map} can't be bound to a macro.)
+Fourth, in Viper, one can define macros that are specific to a given
+buffer, a given major mode, or macros that are defined for all buffers.  In
+fact, the same macro name can have several different definitions: one
+global, several definitions for various major modes, and
+definitions for various specific buffers. Buffer-specific definitions
+override mode-specific definitions, which, in turn, override global
+definitions.
+As if all that is not enough, Viper (through its interface to Emacs
+macros) lets the user define keyboard macros that ask for confirmation or
+even prompt the user for input and then continue. To do this, one should
+type @kbd{C-x q} (for confirmation) or @kbd{C-u C-x q} (for prompt).
+For details, @pxref{Kbd Macro Query,,Customization,emacs,The GNU Emacs
+Manual} @refill
+When the user finishes defining a macro (which is done by typing @kbd{C-x)} ---
+a departure from Vi), you will be asked whether you want this
+macro to be global, mode-specific, or buffer-specific. You will also be
+given a chance to save the macro in your @file{~/.vip} file.
+This is the easiest way to save a macro and make
+it permanently available. If you work your startup files with bare hands,
+here is how Viper saves the above macro so that it will be
+available in Viper's Insert state (and Replace state) in buffer @code{my-buf}
+only:
+@example
+(vip-record-kbd-macro "gg" 'insert-state
+[l up (meta x) n e x t - l i n e return]
+"my-buf")
+@end example
+@noindent
+To do the same for Vi state and all buffers with the major mode
+@code{cc-mode}, use:
+@example
+(vip-record-kbd-macro "gg" 'vi-state
+[l up (meta x) n e x t - l i n e return]
+'cc-mode)
+@end example
+@noindent
+Both macro names and macro definitions are vectors of symbols that denote
+keys on the keyboard. Some keys, like @kbd{\}, @kbd{ }, or digit-keys must
+be escaped with a backslash. Modified keys are represented as lists. For
+instance, holding Meta and Control and pressing @kbd{f4} is represented as
+@kbd{(control meta f4)}.
+If all members of a vectors are printable characters (or sequences, such as
+@kbd{\e}, @kbd{\t}, for ESC and TAB), then they can also be represented as
+strings:
+@example
+(vip-record-kbd-macro "aa" 'vi-state  "aaa\e"  "my-buffer")
+@end example
+@noindent
+Thus, typing @kbd{aa} fast in Vi state will switch Viper to Insert state
+(due to the first @kbd{a}), insert @kbd{aa}, and then it will switch back to Vi
+state. All this will take effect only in the buffer named @code{my-buffer}.
+Note that the last argument to @code{vip-record-kbd-macro} must be either a
+string (a buffer name), a symbol representing a major mode, or @code{t};
+the latter says that the macro is to be defined for all buffers
+(which is how macros are defined in original Vi).
+For convenience, Viper also lets you define Vi-style macros in its Emacs
+state. There is no Ex command, like @kbd{:map} and @kbd{:map!} for doing
+this, but the user can include such a macro in the @file{~/.vip} file. The
+only thing is that the @code{vip-record-kbd-macro} command should specify
+@code{'emacs-state} instead of @code{'vi-state} or @code{'insert-state}.
+The user can get rid of a macro either by using the Ex commands @kbd{:unmap}
+and @kbd{:unmap!} or by issuing a call to @code{vip-unrecord-kbd-macro}.
+The latter is more powerful, since it can delete macros even in
+@code{'emacs-state}. However, @code{vip-unrecord-kbd-macro} is usually
+needed only when the user needs to get rid of the macros that are already
+predefined in Viper.
+The syntax is:
+@findex @code{vip-unrecord-kbd-macro}
+@example
+(vip-unrecord-kbd-macro macro state)
+@end example
+@noindent
+The second argument must be @code{'vi-state}, @code{'insert-state}, or
+@code{'emacs-state}. The first argument is a name of a macro.  To avoid
+mistakes in specifying names of existing macros, type @kbd{M-x
+vip-describe-kbd-macros} and use a name from the list displayed by this
+command.
+If an error occurs during macro definition, Emacs
+aborts the process, and it must be repeated. This is analogous to Vi,
+except that in Vi the user doesn't know there is an error until the macro is
+actually run. All that means that in order for a definition to be
+successful, the user must do some simple planning of the process in
+advance, to avoid errors.  For instance, if you want to map @kbd{gg} to
+@kbd{llll} in Vi state, you must make sure that there is enough room on the
+current line. Since @kbd{l} moves the cursor forward, it may signal an
+error on reaching the end of line, which will abort the definition.
+These precautions are necessary only when defining macros; they will help
+avoid the need to redo the job. When macros are actually run, an error
+during the execution will simply terminate the current execution
+(but the macro will remain mapped).
+A macro name can be a string of characters or a vector of keys.
+The latter makes it possible to define macros bound to, say, double-hits
+on a function key, such as @kbd{up} or @kbd{f13}.
+This is very useful if you run out of function keys on your keyboard; it
+makes Viper macro facility a @emph{keyboard doubler}, so to speak.
+Elsewhere (@xref{Keybindings}, for details), we review
+the standard Emacs mechanism for binding function keys to commands.
+For instance,
+@example
+(global-set-key [f13] 'repeat-complex-command)
+@end example
+@noindent
+binds the key f13 to the Emacs function that repeats the last minibuffer
+command. Under Viper, however, you may still use this key for additional
+purposes, if you bind, say, a double-hitting action for that key to some
+other function. Emacs doesn't allow the user to do that, but Viper does
+this through its keyboard macro facility. To do this, type @kbd{:map }
+first. When you are asked to enter a macro name, hit f13 twice, followed by
+RET or SPC.
+Emacs will now start the mapping process by actually executing
+Vi and Emacs commands, so that you could see what will happen each time the
+macro is executed. Suppose now we wanted to bind the key sequence
+@kbd{f13 f13} to the command @code{eval-last-sexp}. To accomplish this, we
+can type @kbd{M-x eval-last-sexp} followed by @kbd{C-x )}.
+If you answer positively to Viper's offer to save this macro in @file{~/.vip}
+for future uses, the following will be inserted in that file:
+@example
+(vip-record-kbd-macro [f16 f16] 'vi-state
+[(meta x) e v a l - l a s t - s e x p]
+'lisp-interaction-mode)
+@end example
+To illustrate the above point, Viper provides two canned macros, which, by
+default, are bound to @kbd{[f12 \1]} and @kbd{[f12 \2]} (invoked by typing
+@kbd{f12} then @kbd{1} and @kbd{2}, respectively).  These macros are useful
+shortcuts to Viper's command ring history.  The first macro will execute the
+second-last destructive command (the last one is executed by @kbd{.}, as
+usual). The second macro executes the third-last command.
+If you need to go deeper into the command history, you will have to use
+other commands, as described earlier in this section; or you can bind,
+say, @kbd{f12 \3} like this:
+@example
+(vip-record-kbd-macro [f12 \3] 'vi-state
+[(meta x) r e p e a t - f r o m - h i s t o r y]
+t)
+@end example
+Note that even though the macro uses the function key @kbd{f12}, the key is
+actually free and can still be bound to some Emacs function via
+@code{define-key} or @code{global-set-key}.
+Viper allows the user to define macro names that are prefixes of other macros.
+For instance, one can define @kbd{[[} and @kbd{[[[[} to be macros.
+If you type the exact sequence of such keys and then pause, Viper will
+execute the right macro. However, if you don't pause and, say, type
+@kbd{[[[[text} then the conflict is resolved as follows. If only one of the
+key sequences, @kbd{[[} or @kbd{[[[[} has a definition applicable to the
+current buffer, then, in fact, there is no conflict and the right macro
+will be chosen. If both have applicable definitions, then the first one
+found will be executed. Usually this is the macro with a shorter name. So,
+in our case, @kbd{[[[[text} will cause the macro @kbd{[[} to be executed
+twice and then the remaining keys, @kbd{t e x t}, will be processed.
+When defining macros using @kbd{:map} or @kbd{:map!}, the user enters the
+actually keys to be used to invoke the macro. For instance, you should hit
+the actual key @kbd{f6} if it is to be part of a macro name; you do
+@emph{not} write `f 6'. When entering keys, Viper displays them as strings or
+vectors (e.g., "abc" or [f6 f7 a]). The same holds for unmapping. Hitting
+TAB while typing a macro name in the @kbd{:unmap} or @kbd{:unmap!} command
+will cause name completion. Completions are displayed as strings or vectors.
+However, as before, you don't actually type ``"'', ``['', or ``]'' that
+appear in the completions. These are meta-symbols that indicate whether
+the corresponding macro name is a vector or a string.
+One last difference from Vi: Vi-style keyboard macros cannot be defined in
+terms of other Vi-style keyboard macros (but named Emacs macros are OK).
+More precisely, while defining or executing a macro, the special meaning
+of key sequences (as Vi macros) is ignored.
+This is because it is all too easy to create an infinite loop in this way.
+Since Viper macros are much more powerful than Vi's it is impossible to
+detect such loops. In practice, this is not really a limitation but,
+rather, a feature.
+We should also note that Vi macros are disabled in the Minibuffer, which
+helps keep some potential troubles away.
+The rate at which the user must type keys in order for them to be
+recognized as a timeout macro is controlled by the variable
+@code{vip-fast-keyseq-timeout}, which defaults to 200 milliseconds.
+@vindex @code{vip-fast-keyseq-timeout}
+For the most part, Viper macros defined in @file{~/.vip} can be shared
+between Emacs, XEmacs, and X and TTY modes.  However, macros defined via
+function keys may need separate definitions when XEmacs and Emacs have
+different names for the same keyboard key. For instance, the `Page Up' key
+may be known in Emacs as @kbd{prior} and in XEmacs as @kbd{pgup}.
+The problem with TTY may be that the function keys there generate sequences
+of events instead of a single event (as under a window system).
+Both Emacs and XEmacs mape some of these sequences back to the logical keys
+(e.g., the sequences generated by the arrow keys are mapped to @kbd{up},
+@kbd{left}, etc.). However, not all function keys are mapped in this way.
+Macros that are bound to key sequences that contain such unmapped function
+keys have to be redefined for TTY's (and possibly for every type of TTY you
+may be using). To do this, start Emacs on an appropriate TTY device and
+define the macro using @kbd{:map}, as usual.
+@findex @code{vip-describe-kbd-macros}
+Finally, Viper provides a function that conveniently displays all macros
+currently defined. To see all macros along with their definitions, type
+@kbd{M-x vip-describe-kbd-macros}.
+@include viper-cmd.texi
+@node Acknowledgments,,,Top
+@comment  node-name,  next,  previous,  up
+@unnumbered Acknowledgments
+Viper, formerly known as VIP-19, was written by Michael Kifer. Viper is
+based on the original VIP package by Masahiko Sato and on its enhancement,
+VIP 4.4, by Aamod Sane. This manual is an adaptation of the manual for VIP
+4.4, which, in turn, was based on Sato's manual for VIP 3.5.
+Many contributors on the net pointed out bugs and suggested a number of
+useful features. Here is a (hopefully) complete list of contributors:
+@example
+jjm@@hplb.hpl.hp.com (Jean-Jacques Moreau), jl@@cse.ogi.edu (John
+Launchbury), rxga@@ulysses.att.com, jamesm@@bga.com (D.J. Miller II),
+ascott@@fws214.intel.com (Andy Scott), toma@@convex.convex.com,
+dave@@hellgate.utah.edu, cook@@biostat.wisc.edu
+(Tom Cook), lindstro@@biostat.wisc.edu (Mary Lindstrom),
+edmonds@@edmonds.home.cs.ubc.ca (Brian Edmonds), mveiga@@dit.upm.es
+(Marcelino Veiga Tuimil), dwight@@toolucky.llnl.gov (Dwight Shih),
+phil_brooks@@MENTORG.COM (Phil Brooks), kin@@isi.com (Kin Cho),
+ahg@@panix.com (Al Gelders), dwallach@@cs.princeton.edu (Dan Wallach),
+hpz@@ibmhpz.aug.ipp-garching.mpg.de (Hans-Peter Zehrfeld),
+simonb@@prl.philips.co.uk (Simon Blanchard), Mark.Bordas@@East.Sun.COM
+(Mark Bordas), gviswana@@cs.wisc.edu (Guhan Viswanathan),
+meyering@@comco.com (Jim Meyering), pfister@@cs.sunysb.edu (Hanspeter
+Pfister),  amade@@diagram.fr (Paul-Bernard Amade),
+jackr@@dblues.engr.sgi.com (Jack Repenning),
+pogrell@@informatik.hu-berlin.de (Lutz Pogrell),
+csdayton@@midway.uchicago.edu (Soren Dayton),
+pradyut@@cs.uchicago.edu (Pradyut Shah),
+vrenjak@@sun1.racal.com (Milan Vrenjak),
+gvr@@halcyon.com (George V. Reilly),
+whicken@@dragon.parasoft.com (Wendell Hicken),
+terra@@diku.dk (Morten Welinder),
+kanze@@gabi-soft.fr (James Kanze),
+hatazaki@@bach.convex.com (Takao Hatazaki),
+sawdey@@lcse.umn.edu (Aaron Sawdey),
+jobrien@@hchp.org (John O'Brien),
+mrb@@Eng.Sun.COM (Martin Buchholz)
+@end example
+@node Key Index,Function Index,,Top
+@comment  node-name,  next,  previous,  up
+@unnumbered Key Index
+@printindex ky
+@node Function Index,Variable Index,Key Index,Top
+@comment  node-name,  next,  previous,  up
+@unnumbered Function Index
+@printindex fn
+@node Variable Index,Package Index,Function Index,Top
+@comment  node-name,  next,  previous,  up
+@unnumbered Variable Index
+@printindex vr
+@node Package Index,Concept Index,Variable Index,Top
+@comment  node-name,  next,  previous,  up
+@unnumbered Package Index
+@printindex pg
+@node Concept Index,,Package Index,Top
+@comment  node-name,  next,  previous,  up
+@unnumbered Concept Index
+@printindex cp
+@contents
+@bye

Mercurial > hg > xemacs-beta

comparison man/viper.texi @ 0:376386a54a3c r19-14