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
viper-want-emacs-keys-in-vi and viper-want-emacs-keys-in-insert to
nil).
If viper-always is set to t (which is the default), Viper
will try to bring each buffer
in the 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 C-x and C-c. This is why it was so important for us to free up C-x and C-c. It is common for language-specific major modes to bind TAB and C-j (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 (see Customization).
Binding for TAB is one of the most unusual aspects of Viper for many novice users. In Emacs, TAB is used to format text and programs, and is extremely useful. For instance, hitting 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 ) or a " is missing somewhere above the current line, TAB is likely to mis-indent the line.
For this reason, Viper doesn’t change the standard Emacs binding of TAB, thereby sacrificing Vi compatibility (except for users at level 1). Instead, in Viper, the key S-tab (shift+ tab) is chosen to emulate Vi’s TAB.
We should note that on some text terminals, Shift doesn’t modify
the TAB key, so S-tab behaves as if it were TAB. In such
a case, you will have to bind viper-insert-tab to some other
convenient key.
Some packages, notably Dired, Gnus, Info, etc., attach special meaning to common keys like SPC, x, d, 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—it brings them in Emacs state. You can switch to Vi state by typing C-z if, for instance, you want to do Vi-style search in a buffer (although, usually, incremental search, which is bound to 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 just one command. This is done by typing C-c \. (In some of these modes, / and : are bound Vi-style, unless these keys perform essential duties.)
If you would like certain major modes to come up in Emacs state rather than
Vi state (but Viper thinks otherwise), you should put these major modes
on the viper-emacs-state-mode-list list and delete them from
viper-vi-state-mode-list.
Likewise, you can force Viper’s Insert state on a major mode by putting it
in viper-insert-state-mode-list.
It is also possible to impose Vi on some major modes, even though they may
bind common keys to specialized commands. This might make sense for modes
that bind only a small number of common keys. For instance, Viper subverts
the Shell mode by changing the bindings for C-m and C-d using
viper-add-local-keys described in the section on customization
(see Customization).
In some cases, some minor modes might override certain essential
bindings in Vi command state. This is not a big problem because this
can happen only in the beginning, when the minor mode kicks in. Typing
M-x viper-mode will correct the situation. Viper knows about
several such minor modes and takes care of them, so the above trick
is usually not necessary. If you find that some minor mode, e.g.,
nasty-mode interferes with Viper, putting the following in
your Viper customization file should fix the problem:
(viper-harness-minor-mode "nasty-mode")
The argument to viper-harness-minor-mode is the name of the file for the
offending minor mode with the suffixes .el and .elc removed.
It may not be always obvious 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 nasty-mode.el, and see if it has a variable called
nasty-mode-map. Then check if there is a statement of the form
(define-key nasty-mode-map key function)
that binds the misbehaving
keys. If so, use the above line to harness nasty-mode. If your
suspicion is wrong, no harm is done if you harness a minor mode that
doesn’t need to be harnessed.
It is recommended to harness even those minor modes that don’t override
Viper keys, but still have their own keymaps. A general way to
make a minor mode, my-mode,
compatible with Viper is to have the file my-mode.el include the following code:
(when (fboundp 'viper-harness-minor-mode)
(let ((lib (file-name-sans-extension
(file-name-nondirectory load-file-name))))
(viper-harness-minor-mode lib)))