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 C-x e (or *, 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 @a in Vi state (if a macro was previously saved in register a). See 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, :map and :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 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 gg is defined by typing l, the up-arrow key and M-x next-line, its definition will look as follows in Emacs:
[l up (meta x) n e x t - l i n e return]
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 f3 then f2 function keys. (The keys
delete and backspace are excluded; also, a macro invocation
sequence can't start with ESC
. Some other keys, such as f1 and
help, can't be bound to macros under Emacs, since they
are bound in key-translation-map
, which overrides any other binding
the user gives to keys. In general, keys that have a binding in
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 C-x q (for confirmation) or C-u C-x q (for prompt). For details, see Kbd Macro Query
When the user finishes defining a macro (which is done by typing 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 `~/.viper
' 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 my-buf
only:
(viper-record-kbd-macro "gg" 'insert-state [l up (meta x) n e x t - l i n e return] "my-buf")
To do the same for Vi state and all buffers with the major mode
cc-mode
, use:
(viper-record-kbd-macro "gg" 'vi-state [l up (meta x) n e x t - l i n e return] 'cc-mode)
Both macro names and macro definitions are vectors of symbols that denote
keys on the keyboard. Some keys, like \, , or digit-keys must
be escaped with a backslash. Modified keys are represented as lists. For
instance, holding Meta and Control and pressing f4 is represented as
(control meta f4).
If all members of a vectors are printable characters (or sequences, such as
\e, \t, for ESC
and TAB
), then they can also be represented as
strings:
(viper-record-kbd-macro "aa" 'vi-state "aaa\e" "my-buffer")
Thus, typing aa fast in Vi state will switch Viper to Insert state
(due to the first a), insert aa, and then it will switch back to Vi
state. All this will take effect only in the buffer named my-buffer
.
Note that the last argument to viper-record-kbd-macro
must be either a
string (a buffer name), a symbol representing a major mode, or 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 :map and :map! for doing
this, but the user can include such a macro in the `~/.viper
' file. The
only thing is that the viper-record-kbd-macro
command should specify
emacs-state
instead of vi-state
or insert-state
.
The user can get rid of a macro either by using the Ex commands :unmap
and :unmap! or by issuing a call to viper-unrecord-kbd-macro
.
The latter is more powerful, since it can delete macros even in
emacs-state
. However, viper-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:
(viper-unrecord-kbd-macro macro state)
The second argument must be vi-state
, insert-state
, or
emacs-state
. The first argument is a name of a macro. To avoid
mistakes in specifying names of existing macros, type M-x viper-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 gg to llll in Vi state, you must make sure that there is enough room on the current line. Since 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 up or f13. This is very useful if you run out of function keys on your keyboard; it makes Viper macro facility a keyboard doubler, so to speak.
Elsewhere (See Keybindings, for details), we review the standard Emacs mechanism for binding function keys to commands. For instance,
(global-set-key [f13] 'repeat-complex-command)
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 :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
f13 f13 to the command eval-last-sexp
. To accomplish this, we
can type M-x eval-last-sexp followed by C-x ).
If you answer positively to Viper's offer to save this macro in `~/.viper
'
for future uses, the following will be inserted in that file:
(viper-record-kbd-macro [f16 f16] 'vi-state [(meta x) e v a l - l a s t - s e x p] 'lisp-interaction-mode)
To illustrate the above point, Viper provides two canned macros, which, by default, are bound to [f12 \1] and [f12 \2] (invoked by typing f12 then 1 and 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 ., 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, f12 \3 like this:
(viper-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)
Note that even though the macro uses the function key f12, the key is
actually free and can still be bound to some Emacs function via
define-key
or global-set-key
.
Viper allows the user to define macro names that are prefixes of other macros. For instance, one can define [[ and [[[[ 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 [[[[text then the conflict is resolved as follows. If only one of the key sequences, [[ or [[[[ 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, [[[[text will cause the macro [[ to be executed twice and then the remaining keys, t e x t, will be processed.
When defining macros using :map or :map!, the user enters the
actually keys to be used to invoke the macro. For instance, you should hit
the actual key f6 if it is to be part of a macro name; you do
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 :unmap or :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
viper-fast-keyseq-timeout
, which defaults to 200 milliseconds.
For the most part, Viper macros defined in `~/.viper
' can be shared
between X and TTY modes.
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).
Emacs maps some of these sequences back to the logical keys
(e.g., the sequences generated by the arrow keys are mapped to up,
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 :map, as usual.
Finally, Viper provides a function that conveniently displays all macros currently defined. To see all macros along with their definitions, type M-x viper-describe-kbd-macros.
Viper Specials Customization