viper: Packages that Change Keymaps
3.3 Packages that Change Keymaps
================================
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
(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 non-windowing 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 (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)))