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
 (SeeCustomization).
 
    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 (SeeCustomization).
 
    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)))