1. General

ViEmu is a an add-in for Microsoft Word and Outlook, which enables
vi/vim-like editing inside Word and when composing mail messages in Outlook (as long as Word is configured
as the mail editor, which is the default). Based in ViEmu 2.0 for Visual Studio,
with already hundreds of users, ViEmu provides a large
part of the vi/vim input model (motions, commands, operators,
marks, keystroke macros, multiple registers and selection types,
etc..), a larget part too of the ex command line, including its most advanced features (:g, :s, etc...),
and a wide line-up of more advanced feature: vim's visual mode emulation,
advanced keyboard mapping support, and many other features.

It has been tested extensively with Office 2003, Office 2007, and also with Office XP (this is the minimum version with which it works fine).
Support for previous versions of Word/Outlook (Word 2000 and Word 97) out of scope for ViEmu.

This documentation reviews the details of integration with Word and Outlook,
and the vi/vim input model, ex command line, and regular expressions as implemented
by ViEmu.

ViEmu 1.0 was released on January 2007. After extensive testing, and up to 25 different incremental 1.0.x releases,
ViEmu 1.5 was released in July 2008, becoming the "maturity" release of the product.

This release, ViEmu 2.5, brings a few major new features: multiple key chord mappings (for example, ":nmap end $"),
full Ctrl-A/Ctrl-X support to increment and decrement numbers, Ctrl-Y and Ctrl-E in insert mode to copy
text from above or below, and finally, the new licensing key system.

The jump straight from version number 1.5 to 2.5 is in order to sync it with ViEmu/VS and ViEmu/SQL Server.

I hope you will find ViEmu useful!

2. Integration with Word and outlook

You needn't do anything specific to use ViEmu, just open any .DOC or other text file within
Word, and start editing as if you were using vi or vim. The cursor will show
the familiar vi/vim normal mode block shape, and it will respond to regular vi/vim commands as
expected. To use it inside Outlook just try writing a new message or replying/forwarding an existing one.

You can check that ViEmu is working by the light yellow status bar it will show at the bottom of the
current editing window, where partial commands are shown, search/ex editing happens, and status messages are given.

If you want to disable ViEmu temporarily, you can just press Ctrl-Shift-Alt-V in any moment,
and ViEmu will be globally toggled on or off. You can also use the "Enable ViEmu" setting
under the ViEmu Settings dialog, brought up by clicking on the "ViEmu Settings" button that ViEmu adds.
While it's turned off, Word/Outlook will work the same as if ViEmu were not installed.

3. ViEmu preferences

ViEmu preferences are accessible from the ViEmu Settings toolbar button. The following
dialog will pop up to allow customizing ViEmu.

3.1. Main preferences page

Enable ViEmu: As mentioned above, use this checkbox to enable or disable ViEmu
within Word and Outlook.

Ignore CAPS LOCK state in NORMAL: if this option is selected, ViEmu will look at the actual state
of the SHIFT key when a command was issued, instead of paying attention to the CAPS LOCK key state. One of the
most common inconveniences with the vi/vim input model is that the lowercase and uppercase version of a character
invoke different commands, and if you accidently hit the CAPS LOCK key, you will be invoking the uppercase version
when you intend to invoke the lowercase version and viceversa, which is a minor but annoying source of confusion.
This option helps by keeping the regular command behavior even with CAPS LOCK set, and lets you discover the
pressing of CAPS LOCK when you start actually typing text, which is much less of a hassle.

Default to Windows clipboard: in vim, you need to use the "*" register specifier to
actually copy (yank) to or paste from the Windows clipboard. Unspecified yanks or pastes use the internal "0"
register. If you check this option, ViEmu actually uses the "*" by default with every yank/paste, which makes
it more convenient to interact with other Windows applications. The "*" still works in ViEmu to explicitly access
the Windows clipboard (both with this option set or unset).

Beep on errors: ViEmu will beep when some invalid input is received if this option is selected, in
the same way that vi/vim do. Uncheck it to have a "silent" ViEmu.

Windows-like word wrap navigation: ViEmu can emulate vim's behavior in which j/k move to the physical
lines (Word paragraphs) above or below the current one, making them jump several lines in the case of word wrapped lines. With this
option enabled, which is the default
setting, the j/k motions will move by screen lines, resembling the default behavior of the Up and Down cursor keys in
Word/Outlook and most Windows applications. 0 and $ will also move to the beginning and the end of the current 'wrap' portion.
Line ranges are still considered by physical division, so 'dd' will erase a full line/paragraph, even if it is wordwrapped into
several visual lines.

Force no smart cut and paste: By default, Word has a "Smart cut/paste" user settting enabled, which uses some heuristics to delete
additional whitespace, etc... when deleting selections. This also affects ViEmu deletions, such that if you do 'de' at the beginning of a word,
Word will decide to also remove the spaces after the word. Since this is not usually what you want, ViEmu can automatically disable
the option in the current window so that it won't interfere with regular vi editing.

Update display during long commands: This setting controls whether partial edits (such as individual substitutions in a %s command)
are allowed to update the screen while operating. It's usually better to leave this turned on in order to gain feedback on the operation, and
some times Word or Outlook flicker if screen update is disabled.

Enable vi/vim block caret: Have ViEmu use a block cursor, better resembling the usual vi/vim cursor shape. Since it is not possible
to customize the caret in Word, the effect is achieved by having a one-character-wide selection in the document (except in visual mode). The net
effect is that this cursor won't blink. The effect is quite nice and very usable, but if you prefer a blinking caret with the gotcha that it will
be a vertical line, you can control it with this setting.

Use Word's formatted copy/paste for system clipboard: When copying to or pasting from the system clipboard (either by using the "* register
identifier, or by giving no identifier if the above "Default to Windows Clipboard" is enabled), ViEmu can use Word's underlying copy/paste mechanims.
This will allow moving around formatted text (ViEmu's named registers - "a to "z, etc... - are raw-text only). The only limitation of this option
is that multi-line character-wise regions will be copied/pasted linewise (due to a difficult compatibility problem with the underlying Word copy/paste mechanism).

Implement insert mode passing all input to Word: This setting enables a mode of ViEmu in which virtually all insert mode input is passed
to Word for processing, instead of performing the actions directly. This enables autostyling, autocorrection, auto-bullet lists, etc... at the expense
of disabling input mode key remapping (:imap), and of having slightly different results when repeating input using '.' or macros. A few keys are still
processed by ViEmu (Ctrl-R to recall the contents of a register, INSERT to toggle overstrike on/off, etc...).

ignorecase, smartcase, incsearch, hlsearch: These options control the vi/vim standard variables of the same names,
which are usually accessed using the :set commmand. Unlike when setting them using the :set command, when set through
this dialog their value is persisted by the preferences system.

ignorecase controls the case sensitivity of the searches done using the '/' and '?' commands.

smartcase: This option activates 'Smart case sensitivity'. This setting only works if 'ignorecase' is on.
In that situation, if a search string is entered containing at least one upper-case character, case-sensitive behavior is
used for that search. These allows using case insensitive searches most of the time, by typing only lowercase characters,
and still for case sensitive behavior for a given search by typing some uppercase character.

incsearch this setting controls incremental search, that is, whether the cursor is placed at the first
match of the search target while the search is being typed (the match is also higlighted).

hlsearch this setting controls search highlighting, which will mark with a different background the all matches
of the search string in the current file. It will also highlight them when switching to a new file. Although ViEmu
goes to great lengths not to scan unnecessarily, this feature may impact performance in the case of very large files.

Keyboard button: this button brings up the keybinding management dialog.

The bottom of the preferences page provides link to this documentation, to the ViEmu Software web site,
and a note on the registration info of the current copy of ViEmu.

3.2. Keyboard management tool

When you click on the 'Keyboard' button in the main ViEmu preferences page, the following dialog is displayed:

By default, ViEmu filters all keystrokes, processes them if they mean something for the vi/vim emulation core, and passes them
on to Word only if they have no meaning in vi/vim. This allows overriding default Word keybindings (such as Ctrl-F for "Find", instead
of vi/vim's default "Page down"), and also assigning mappings to keystrokes that have a default meaning in Word (you can map Alt-F,
although this will prevent the keystroke from bringing up the "File" menu).

This configuration dialog allows you to designate certain Ctrl-key combinations to pass on directly to Word without further
inspection. The default Cut/Copy/Paste/Undo combinations are configured to be passed on this way, to enable better
coexisting of ViEmu with expected Word behavior.

Also, ESC in normal mode and function-key combos can be configured to be passed through by using this dialog.

4. The status bar

When you are editing a file with ViEmu, you will notice there is a new light-yellow status bar at the bottom of the current
editing window. This status bar shows the current state
of ViEmu: it first shows the mode ViEmu is in (NORMAL, INSERT, REPLACE, VISUAL, VISUAL-LINES or VISUAL-BLOCK),
but apart from this, it also shows the current partial command that you have input, as is common in vi/vim.

Another overlay window will come up for ex commands that result in output (:p, :#, :ls, etc...), and also to report errors
detected in the configuration .viemuwrc file sourced on startup.

5. Miscellaneous integration info

Vi lines are assigned to Word paragraphs, but j/k/0/$ move
visually (the way gj/gk/g0/g$ work in vim) by default, and the g*
versions act like the regular j/k/0$. This can be toggled with a
ViEmu user setting ("Windows-like word wrap navigation"). The
reason for this is that Word/Outlook editing is usually done on
wordwrapped paragraphs, and regular j/k... just don't cut it
there.

Named registers are raw-text only (no formatting is copied/pasted)

Block selections (Ctrl-V or Ctrl-Q in vim) are disabled. There
simply is no way to display it in Word. I do plan to try to
implement some way to paint over Word's own window for this, in a
future release

:e and :w accept no arguments, they just call File|Open and File|Write

Table navigation can be a bit weird at first - j/k go to the
cell below/above, but you can use to gj/gk to go the cell on the
right/left (because that's Word's paragraph ordering)

Word's auto-correction-while-typing is disabled. Support for
this is planned for a future version.

Features planned for future releases: formatting operators
(bold, underline, ... (keypress sequences for this are not
decided yet), a :send command for Outlook email composing,
etc...

The support for the whole :*map familiy of functions
(including their regular and their :*noremap side) is fairly
complete, with a single exception: only single keypresses can be
mapped (although they can be mapped to an unlimited sequence of
keystrokes). Mapping of 'chords' (for example, ":map c_ ct_")
requires managing ambiguous input sequences and timing limits to
resolve them, and this will be implemented in a later version of
ViEmu.

ViEmu does its own clipboard handling, both for internal named
registers (0-9, a-z) and for the default clipboard. These
internal registers are raw-text only (no formatting), but this
allows ViEmu to recreate vi/vim's distinction of character, line
and block selections. This may not work well with other clipboard
enhancers. If you have enabled "Use Word's formatted copy/paste
for system clipboard", which is the default setting, ViEmu will
try to emulated vi/vim's default behavior on top of Word's
copy/paste functionality, allowing you to manipulate formatted
text.

Althouh I've tried to implement ViEmu in the most compatible
manner, ViEmu may not work well (or at all!) with other add-ins.
Please tell us any
compatibility problems you may find.

You can use the combination Ctrl-Shift-Alt-V in any moment to
globally toggle ViEmu on or off.

Please take into account that once you select some text using
external methods (dragging the mouse, bringing up Word's find
dialog, etc...), ViEmu will automatically enter visual selection
mode. You need to exit visual mode explicitly with ESC if you
want to revert to normal mode.

6. The vi/vim input model

We have made available a
vi/vim graphical reference and tutorial,
which covers the most important part of the vi/vim input model. Be sure to check it out if you want a good reference
or a general introduction to vi/vim editing.

ViEmu accepts commands along the vi/vim input model. This means that input is separated in pieces that are parsed as they
are entered, and the command is 'kicked' when the parsing determines that there is a complete command to execute. The partial
input entered up to the moment is displayed on the status bar. An incomplete command can be cancelled by pressing ESC.

A command may be composed by the following elements:

One or more register specifiers (a quote followed by another character, for example, "a)

One or more counts (a decimal number, such as 12)

A command (which may be followed by other elements depending of the type of commands)

All commands may be preceded by a count that usually indicates the number of times to perform the command,
and a register specifier, which indicates which register to use in the case of yank/paste/delete commands.
If there is more than one count present (separated by another input element), the different counts are multiplied together.

Some commands are direct-action commands (for example, 'x' deletes the current character). These commands kick ViEmu
to act as they are typed, optionally with a count and/or register specifier.

Other commands require a character argument (for example, 'm' which requires a mark identifier afterwards, or
't' which expects which character to look for after it). These commands wait for the character and then kick
the action.

Another set of commands are called 'motions', which involve moving around the edited file. They are also kicked as
soon as typed (for example, 'l' means 'move cursor right' or 'w' means 'next beginning of word).

Finally a very important set of commands are called 'operators'. These commands act upon a region of text doing some
action on it (for example, 'd' deletes the region, 'gU' makes it uppercase, and 'y' copies the region to a register).
These commands wait for a motion after entering them, and then act on the text between the current position and the
motion target. The motion can have a count itself, such that 'd2w' deletes the next two words. In visual selection mode,
operators don't wait for a motion and, instead, act on the selected region of text - this is an improvement of vim
over the original vi and is actually very useful.

ViEmu implements most of vi/vim's core commands, including operators and motions. Some obscure ones are not implemented (such
as ROT13 encoding), as well as some advanced ones (such as line autocompletion in input mode).

Motions

0: move to hard beg-of-line (column 0)

'$': move to end-of-line

'^': move to soft beg-of-line (first non-space character)

'-': move to soft beg-of-line of the previous line

'+', <RETURN>: move to soft beg-of-line of the next line

'_': move to soft beg-of-line of the current line (if count given, N lines below)

'|': move to column as given by count (default 0)

hjkl move left, down, up and right

Ctrl-P/Ctrl-N: up and down (same as k/j)

w: move to next beginning of "word"

b: move to previous beginning of "word"

e: move to next end of "word"

ge: move to previous end of "word"

W: move to next beginning of "WORD"

B: move to previous beginning of "WORD"

E: move to next end of "WORD"

gE: move to previous end of "WORD"

f* ('*' is any character you type): move to next appearance of the character in this line

F*: move to previous appearance of the character in this line

t*: move to just before the next appearance of the character in this line

T*: move to just after the previous appearance of the character in this line

'`*' ('*' is a mark specifier): move to the position of the given mark) - mark '.' is the last edited position,
'<' and '>' are the last visual selection endpoints, '[' and ']' are the start and end-point of the last
text modification, yank or paste, and '^' is the location where insert mode was last exited. Lowercase marks are local to the buffer,
uppercase ones are global (and jumping to them isn't really a 'motion')

''*' ('*' is a mark specifier): move to the soft-beg-of-line of the position of the given mark)

gg: move to the top of the file (if a count is given, move to that line)

G: move to the end of the file (if a count is given, move to that line)

'%': move to the matching parenthesis (or similar). If not on matching character, first scan for the next matching character
on the line. If beyond end of line, try maching at the last character of the line. If a count is given, move to that percent of the whole file instead

'/arg<return>': (find) move the next occurlnce of "arg" in the file - incrementally shows place while parsing, but you can press ESC to cancel it and go back to where you where

'?arg<return>': same as previous one, but backwards

n: repeat last find ('/' or '?', or '*' or '#')

N: repeat last find with reversed sense (will do backwards if it was '/' or forwards '?')

'*': (literal asterisk) find the next occurrence of the identifier under the cursor

'#': (literal hash) find the previous occurrence of the identifier under the cursor

'g*': (literal asterisk) find the next occurrence of the identifier under the cursor, not required to be a full-word match

'g#': (literal hash) find the previous occurrence of the identifier under the cursor, not required to be a full-word match

Ctrl-d: move the cursor down and scroll half a screenful of text - this works in vim, but is not a motion

Ctrl-u: move the cursor up and scroll half a screenful of text - this works in vim, but is not a motion

Ctrl-f: move the cursor down and scroll a screenful of text - this works in vim, but is not a motion

Ctrl-b: move the cursor up and scroll a screenful of text - this works in vim, but is not a motion

( or ): move to previous beginning or next end of sentence, as indicated by periods or other punctuation signs.

{ or }: move to the previous beginning or next end of paragraph, as indicated by fully empty lines

[[ or ]]: move to the previous or next open brace in the first column - useful to navigate C/C++ source code.

[] or []: move to the previous or next close brace in the first column - useful to navigate C/C++ source code.

z<return>, z. or z-: move to the soft beg-of-line, but also scroll the file to put the current line at the top/center/bottom of the screen

[( and ]): move to previous or next unmatched parenthesis - it steps over properly matched parentheses

[{ and ]}: likewise with braces

Ctrl-i and Ctrl-o: move to next or previous position in the "position history" of last visited places. If the previous position is in another file, it doesn't act like a motion, but if it is on the same file, it acts as a motion (unlike vi/vim.)

special text-block motions: these motions act especially, as they determine not only the end but also the
beginning of the acted upon region. They cannot be entered as regular motions in normal mode, as they
start with 'i' or 'a' which are valid commands - they can only be used as arguments to operators or in visual mode.
They fully determine the region on which to operate when used as operator arguments, and they extend the
current selection in visual mode. The 'inner' version does not pick spaces afterwards, while the 'a' version does:

^Ws: split current window if it's not already a split (^W means Ctrl-W)

^W^W, ^Ww, ^Wj, ^Wk, ^W plus up/down cursors: toggle from one split of the current pane to the other

zc, zo, za or zA: toggle the current fold from open to closed, or viceversa

zd: remove the current fold (not the text, but just the fold markers)

zR: expand all folds

zM: collapse all folds

gf: open file under cursor

gt/gT: go to next/previous buffer in buffer list

ZZ: save current file and close it (same as :wq)

Ctrl-A/Ctrl-X: increment/decrement the number under the cursor (decimal, hex, octal and alpha supported, see nrformats option)

'.': (probably the most useful vi/vim command) repeat last command

Operators

They all wait for a motion in normal mode or act on the visually selected region in visual selection mode. They all
use the specified register if there is one, or the default if there is no one specified (default may be the "*" Windows
clipboard or the internal "0" register depending on an options on the preferences page).

d: delete the specified region

c: delete the specified region and enter input mode

y: yank (copy) the specified region

gU: make all the characters in the specified region uppercase

gu: make all the characters in the specified region lowercase

g~: toggle the case of all the characters in the specified region

>: indent all the lines in the specified region

<: unindent all the lines in the specified region

Other

In insert mode, you can use the special Ctrl-T and Ctrl-D to indent/unindent the currently edited line.
Also in insert mode, Ctrl-Y copies the character from the line above, and Ctrl-E the one from the line below.
In insert and command line editing mode, you can use Ctrl-R followed by a register specifier to recall the
contents of that register (use " or any other non-alphanumeric symbol after Ctrl-R to recall the contents
of the default register).
While editing at the command line, be it a '/' or '?' search or an ex command line, you can use Ctrl-Y to yank
the full contents of the command line into the default register/clipboard.
Also in insert or command line editing mode, Ctrl-U deletes back to the start of the edit, and Ctrl-W deletes the word before the cursor.

7. Regular expressions

7.1. Introduction

Regular expressions are a well known method by which to specify patterns for text searching.
Most characters in a regular expression represent themselves, so "ten" interpreted as a regular
expression represents the sequence of characters 't', 'e', and 'n', and searching for it will
yield all places in the text where the string "ten" appears. Some other characters represent
a pattern-matching element, for example, searching for "a*" will yield all sequences of 'a's
(given that '*' represents zero-or-more repetitions of the previous element, in this case,
the character 'a'). If you want to search for a sequence containing the character '*',
you have to 'escape' it so that the regular expression engine will understand 'the literal
star character' - this is done by prepending a backslash ('\') to the character. Thus,
searching for "a\*" will yield all places in the text where the sequence 'a','*' appears.

The single other most known regular expression element is the dot ('.'), which matches
any single character in the input.

ViEmu accepts a large subset of the regular expression features understood by vim. vim,
on the other hand, accepts a superset of the features and syntax understood by traditional vi.
Actually, ViEmu is also a superset of traditional vi regular expressions (smaller than vim).

For the technically inclined, the regular expression engine that ViEmu uses is an implementation
from scratch based on non-deterministic finite automata. Additional state is stored for previously
matched subexpressions, positions in the input stream, and repetition counts, in order to implement
the most advanced features. The regex engine compiles the expression down to a bytecode-based format,
and then the matching engine "executes" this bytecode on the input stream to find matches.

7.2. Searching vs matching

In the rest of this section, we will talk about regular expression elements "matching" parts
of input text. Usually, regular expressions are not simply checked to match - when you press '/' in
normal mode and enter a regular expression, several things happen. ViEmu compiles the regular expression
into an intermediate form, and then it checks whether it matches at the character position right after
the one where the cursor is. But if it doesn't match, things don't stop there - given that we're searching,
another attempt to match is made at the position after the first one. And on the next, and the next... until
the whole file is scanned or a match is found.

When showing examples, we will be showing what text matches a regular expression, but we will also
be saying "it matches at the third character", meaning that it doesn't match at the first or second ones".

Not only that, but given that the regular expression actually matches a part of the input text, we will
be talking about the regular expression matching a precise part of the input stream. For example, I could say the
regular expression "a\+" tested against "bcaade" matches the two 'a's in the middle, meaning that it
doesn't match at either the 'b' or the 'c', but it matches at the first 'a' and the match covers the two 'a'
characters.

A regular expression element can match a varying amount of the input sequence. "a", for example, will
match an 'a' character in the input and consume that character, so that the next regular expression element
will try to match the next character in the input. "a*", on the other hand, may consume anything from zero
characters (if the character found there is not an 'a', in which case the match is done assuming zero
appearances of 'a'), one (if there is a single 'a' in the input and something else afterwards), or five
characters (if there are 5 'a's in a row and something else comes afterwards). We talk about zero-width
matches for those that do not consume any input character. For example, 'a*' can match with zero-width or
non-zero widht, as we've just seen. On the other hand, some regular expression elements that we'll see
below always match with zero-width, that is, they check their matching condition, and if this is
fulfilled, they keep trying to match the rest of the regular expression without advancing to the next
input character.

7.3. Magic

ViEmu actually understands different regular expression syntax "flavors". They are actually the
four different flavors supported by vim: verynomagic, nomagic, magic, and verymagic. As you can imagine,
they are in increasing order of "magicness". What does this mean? It represents the amount of easiness
with which vim or ViEmu understands a character with a special meaning to stand for its special meaning
instead of as a literal char.

Take for example the '*' character. We've seen that, if you use this character
in a regular expression, it will be taken as meaning "as many repeats as wanted, even zero, of the
previous character". If we want our regular expression to match an actual "*" in the source text, we need to
escape it by writing "\*".

This is actually the behavior of the '*' character in 'magic' mode, which is the default mode. If we
instruct vim or ViEmu to parse the regular expression in 'nomagic' mode, a naked "*" by itself will have
no special meaning, and a sequence "\*" will be necessary in the regular expression for the regular expression
parser to understand "zero-or-more repetitions of the previous character".

The default parsing mode can be set to either 'magic' or 'nomagic', by use of the :set command. ":set magic"
and ":set nomagic" do the trick for both modes. It is not possible to specify a 'verynomagic' or 'verymagic'
parsing default, if you want to write a regular expression in one of these modes, it's necessary to start the
regular expression with "\v" for 'verymagic' or "\V" for 'verynomagic' (actually, these can be inserted
anywhere in the input regular expression and they set the parsing mode until the end of the regular expression,
or until another mode-setting token). There are also sequences to set the mode to 'magic' or 'nomagic', namely,
"\m" to set 'magic' and "\M" to set 'nomagic' - inserting these tokens sets the parsing mode overridingthe
':set [no]magic' state.

The mode 'verynomagic' is defined as not giving a special meaning to any character unless it's escaped -
so it is the best mode if the string you want to match contains a lot of punctuation which is also used in
regular expressions, and few regular expression control characters. The mode 'verymagic' is defined as giving
a special meaning to any punctuation character which has a meaning in regular expressions, unless it is
escaped with a backslash. Thus, it is most useful if you are trying to match a string with not very many
special punctuation characters, but the regular expression has quite some repetition, grouping, etc... control
characters.

Each regular expression character gains its special meaning in a certain 'magicness' level. The decision
seems arbitrary, but it's probably due to making the magic mode as compatible as possible with traditional
vi.

For example, the '+' character is taken as meaning "one or more repetitions
of the previous element", almost the same as '*' but it will require at least one occurrence of the element
to match. '*' in magic mode is taken for its special meaning, while '+' is not taking as such, and requires
a backslash in order to be interpretead for its repetition meaning. This is probably due to '+' being a feature
not present in the original vi. Of course, both '+' and '*' are taken as repeat indicators in 'verymagic' mode,
and taken as regular characters in 'verynomagic' mode.

So, some characters gain a special meaning in 'magic' mode (such as '*'), and others gain their
special meaning only in 'verymagic' mode (such as '+'). But what characters gain a special meaning
in 'nomagic' mode? That is, what are the (few) characters that are already interpreted specially in
'nomagic' mode? Actually, although the vim documentation is not completely clear with regards to this,
it seems only '^' (beginning-of-line) and '$' (end-of-line) are already special in 'nomagic' mode
(we'll see the meaning below, and an important note is that these characters only have a special
meaning in certain positions of the regular expression)

For the rest of the documentation, we will list each element in the way it works in 'magic' mode.
There is a table of the interpretation of all special characters in each mode at the end of the section.

7.4. Basic multis

Apart from literal characters, the most basic element in regular expressions are 'multis' or
repeat specifiers. These are the basic multis understood by ViEmu:

* zero or more

\+ one or more

\= zero or one

\? zero or one (same as =)

Let's see some examples of them applied to regular characters:

a\+: This matches "a", "aa" or even "aaaaaa". It matches the two 'a's in "bbaacc".

a*: This matches the empty string, "a", "aa" or even "aaaaaa". In "bbaacc", it matches
at the first character consuming no input (as zero repetitions are allowed, and there are zero 'a's
at the first position).

a\=b: matches "ab", "b", and matches "cdeb" at the 'b' character.

The multis actually apply to the previous element in the regular expression - this can be a character
(the examples we've just seen), any of the atoms described below (sets, character classes, etc...) and
it can also be a subexpression delimited by parenthesis.

7.5. Beginning and end of line

The characters '^' and '$', which are recognized specially even in 'nomagic', stand for start-of-line and
end-of-line. They actually match with zero-width, and they provide a way to 'anchor' the regular expression
to the start or end of line. "^a" will match an 'a' only as the first character of the line, and " $" will only
match a trailing space (and only the last one if there are several).

These characters are only interpreted as special if they are the first or the last character in the
regular expression. If they are anywhere in the middle, they are taking as literal characters. If you want
to use them anywhere in the regular expression, you need to use the sequences "\_^" and "\_$", which
are always recognized as meaning start- and end-of-line.

vim also gives '^' and '$' special meaning at the start/end of subexpressions and branches,
but ViEmu doesn't. As a workaround, you can use the "\_^" or "\_$" forms instead.

7.6. Sets

A set is formed, in its simplest form, by a list of literal characters enclosed between square brackets
('[' and ']'). It matches any of the characters in the set, and none other. For example, "[abc]" matches "a",
"b" or "c", but not "d" or any other character.

But sets have a lot of advanced features to make them more useful. For example, "[0123456789]" would match
any decimal digit, but you can use the shortcut "[0-9]" to represent all characters between '0' and '9', both
included. A set can feature any number of ranges, together with independent characters: "[_a-zA-Z0-9]" represents
any alphanumeric character or the underscore character, thus matching any character in a C or C++ identifier. If
you want to include a literal hyphen in a set, give it as the first character in the set: "[-0-9]" means any digit
or the hyphen character.

It is also possible to specify negative sets, that is, the set of all characters but the ones
specified. This is done using the caret or circumflex: "[^0-9]" matches any character which is not a decimal digit.
If you want to specify a caret among the characters in the set, just don't put it as the first character: "[0-9^]"
represents any digit or the caret.

If you want to include the closing square bracket in a set, give it as the first character: "[]0-9]" means,
a bit confusingly, any decimal digit or the closing square bracket.

Sets also allow four "character class tokens". These tokens match, each of them, a certain set of characters.
The way to write them is surprisingly verbose:

[:alnum:]: alphanumeric character (same as [0-9A-Za-z])

[:cntrl:]: control character (ascii 0 through 31)

[:graph:]: printable character excluding space (ascii 33 through 126)

[:punct:]: punctuation character (those for which the system's ispunct returns true)

They can be used together with other characters and ranges, or on their own: "[[:alnum:]]" is the
same as "[0-9A-Za-z]", but you can also use "[,[:alnum:].;]" to match alphanumeric characters, ',', '.'
or ';'.

Multis can be applied to sets, such that "[0-9A-Za-z_]\+" will match any C/C++ identifier (and those
pseudo-identifiers starting with a digit).

7.7. Character classes

There are some special sequences that are taken as representing a set of characters. These sequences are
of the form "\x" where x is an alphabetic character. This is the list of character classes recognized by
ViEmu (the same as vim):

\i: identifier [_a-zA-Z0-9] (isident)

\I: identifier w/o digits [_a-zA-Z]

\k: keyword [_a-zA-Z0-9] (iskeyword)

\K: keyword w/o digits [_a-zA-Z]

\f: filename [_a-zA-Z0-9./\\] (isfname)

\F: filename w/o digits [_a-zA-Z./\\]

\p: printable [ -~] (isprint)

\P: printable w/o digits [ -/:-~]

\s: whitespace [ \t]

\S: not whitespace [^ \t]

\d: digit [0-9]

\D: not digit [^0-9]

\x: hex digit [0-9A-Fa-f]

\X: not hex digit [^0-9A-Fa-f]

\o: octal digit [0-7]

\O: not octal digit [^0-7]

\w: word [0-9A-Za-z_]

\W: not word [^0-9A-Za-z_]

\h: head of word [A-Za-z_]

\H: not head of word [^A-Za-z_]

\a: alphabetic [A-Za-z]

\A: not alphabetic [^A-Za-z]

\l: lowercase [a-z]

\L: not lowercase [^a-z]

\u: uppercase [A-Z]

\U: not uppercase [^A-Z]

The pattern is that lower case letters represent a certain class, and their uppercase counterpart represents
either the same class without the 0..9 digits, or a character not belonging to the original class.

The weird ranges in \p and \P represent ASCII values 32..126 (for \p), and that range minus '0'..9' for \p.

vim allows redefining the \i, \k, \f and \p sets (and their uppercase counterparts) through the isident, iskeyword,
isfname and isprint options. ViEmu hardcodes them to their default vim values.

There are also four other character classes (alphanumeric, control-codes, graphic and punctuation) which are only
available within sets (see above).

As an example, "^\s*\S\+\s*$" matches full lines consisting of a single word formed by non-whitespace characters,
possibly with leading and trailing whitespace. A line like " abc " would match, where " ab cd " wouldn't.

7.8. Subexpressions

You can group parts of a regular expression between parentheses (by default "\(" and "\)", which are quite
ugly and unreadable, but you can use "\v" at the beginning of the expression to use simple '(' and ')'). Adding
doesn't change the interpretation of regular characters, but you can make a multi apply to a whole subexpression
this way:

"\(ab\)c" matches the same as "abc", namely, the "abc" string

"\(ab\)*c" matches any count of "ab" pairs followed by a 'c'. For example,
it matches "abc", but it also matches "ababc", "ababababababc", and even just "c".

You can also nest them, which combined with other features is pretty powerful: "\(a\(bc\)\+\)*"
matches any number of "abc"s followed each of them by as many "bc"s as wanted: "abcbcbcabc" and "abc" are
matched, and "def" is matched but with zero width (no repetitions).

Subexpressions given this way can be later refered to in the regular expression with "\1", "\2",...
up to "\9". When this appears in the regular expression, it only matches the text that matched the
subexpression. For example, given that "\d\+" matches any integer decimal number,
you can search for "\(\d\+\) \1" which will find repetitions of numbers separated by a space
(for example, "58 58" but not "58 59"). Be careful, because done this way it can match unexpected
sequences, such as "58 583" by ignoring the last '3'). In order to do this correctly, have a look at
section 7.11 for word begin / word end.

Subexpression numbers are assigned left-to-right by opening parenthesis order as they
appear in the regular expression.

If you want to include a subexpression, but are not interesting in refering to it later (either
by the \1..\9 tokens described in the paragraph above, or in the :s substitution command), you can
open the subexpression with "\%(", which will work the same, not count towards the \1..\9 tokens,
and result in a tiny bit faster regular expression when it comes to checking it (use "\)" as normally
to close it).

7.9. Advanced multis: counted repetitions and greediness control

Apart from the multis we've seen above, there is another set of multis which allows more
control on the repeat counts accepted. But before getting into them, I'll discuss an important
aspect of regular expression matching: greediness.

When a pattern involving repetitions is tried to match, it is actually tried to match with
the different possible amount of repetitions. For example, if the pattern specifies "a*" and
the text contains three 'a's ("aaa"), the regular expression item could be match with zero, one,
two or three repetitions. Matches with different repeat counts are attempted, and the first one
that makes the whole pattern match is returned. Given that different repeat counts may cause a
match, the order in which counts are attempted is very important towards the final match.

A repeat operator that attempts to first match as many valid input characters as possible
is called a greedy operator. All multis we saw in section 7.4 are greedy, so actually
"a*" will try to match the three 'a's in the example above. If "a*" is the whole pattern, and the
input sequence starts with three 'a's followed by something else, that is the end of the story
and the three-'a' match is returned. But if the regular expression were "a*a", and the input
still "aaa" or "aaab", it's not the end of the story. First, the "a*" tries to match the three 'a's,
but then the last 'a' in the regular expression tries to match and fails. Thus, a match is tried
to make with the first "a*" matching just the first two 'a's. Then, the next 'a' in the regular
expression tries to match, and succeeds - so the "aaa" in the input text is returned as matching,
by attributing two repetitions to the '*' character.

The operator which is the center of this section is the counted repetition operator,
which is expressed by "\{" (and needs a closing "}" afterwards). It can contain two numbers separated
by a comma, which are interpreted as a minimum and maximum count. For example, "a\{2,3}" will match
two or three 'a's, but not zero or one, or more than three. Both counts are optional: if the minimum
is not present, it is taken as zero, and if the maximum is not present, there is no maximum. Thus,
"a\{,5}" means zero-to-five 'a's, and "a\{3,}" means three or more 'a's. If a single number is present,
it is taken as meaning exactly that many repetitions. Thus, "a\{3}" will match only
three 'a's.

Given as above, the "\{" operator also acts greedily: it will try to match as many
input characters as it can, and only try to match less repetitions if the whole pattern
didn't match after the attempted count. But if there is a hyphen just after the "\{"
opening brace, the operator acts non-greedily: it will attempt to match as few input
characters as possible. For example, if the regular expression "a\{-2,}" is tried to match
with the input "aaaaa", it will only match the first two 'a's. It could match the
whole input, but it tries not to. A regular expression such as "a\{-2,}b" will, though, match
the complete "aaaaab" input - the operator needs to consume all 'a's for the 'b' to match.

As a special case of this behavior, "\{}" is the same as "*", and "\{-}" is a non-greedy
version of the '*' operator.

7.10. Case sensitivity

Case determination is done as is default given the ViEmu 'ignorecase' and 'smartcase' options.

If 'ignorecase' is turned off, every character matches only itself.

If 'ignorecase' is turned on and 'smartcase' is turned off, the pattern
is tried to match disregarding case.

If both 'ignorecase' and 'smartcase' are turned on, then the behavior is a bit more interesting.
The first thing done is to check whether the pattern contains any uppercase character. If it
doesn't contain any, then the match is tried without paying attention to case. But if the regular
expression contains any uppercase character, then the match is attempted without ignoring case.
This allows using case-ignoring searches most of the time, and forcing a case-sensitive search
by just using any uppercase character in the string.

Apart from this global settings, it is possible to force a regular expression to either
check or ignore case. By including the "\c" sequence anywhere in the pattern, the pattern will
always be checked ignoring case. By including "\C", the pattern will always be checked paying
attention to case. These sequences can be given anywhere in the pattern, and they affect the whole
matching process (not only the part after them). They do not take part in the actual pattern
matched, so they can be given anywhere in the pattern without changing its properties

Using these flags, if you set both 'ignorecase' and 'smartcase', you can still force a
case-sensitive search of a lowercase-only pattern by preceding it with "\C": "\Cabc" will only
match "abc", not "ABC" or "Abc".

Character classes, both the regular "\x" ones explained in section 7.7, and the set-specific
ones shown in section 7.6, use the case-sensitivity associated with their definition, independently
of both global settings and the "\c" or "\C" sequences.

7.11. Miscellaneous

Word beginning/end

In the same way that '^' and '$' provide a way to "anchor" the pattern to the beginning
or end of a line, the tokens "\<" and "\>" provide a way to anchor a pattern to the
beginning or end of a word. The beginning of a word is defined as a word character
([_a-zA-Z0-9]) following a non-word character (or at beginning of line). The end of a word
is defined as a non-word character or end of line, after a word character. These are
zero-width matches.

Using these tokens, we can perfect the regular expression shown above in section 7.8 to
detect pairs of repeated decimal numbers: "\(\<\d\+\>\) \<\1\>"
will match "53 53" or "47 47", but not "53 538" or "112 12". It is much easier to read
in verymagic mode: "\v(<\d+>) <\1>" (at least, less hard to read, and if that
seems unreadable, have a look at the html source).

Match-extent override

It is possible to instruct the pattern matching engine to check for a large pattern,
but only return a part of the matched text when the match succeeds. This is done by using
the "\zs" and "\ze" start and end tokens to indicate where the overriding match start and
end should be placed. For example, "abc\zs123\zedef" will only match a "abc123def"
sequence, but only the "123" part will be returning as matching (ie, it simply won't match
"zzz123yyy" at all). This is very useful with the :s ex substitution command: only
the delimited text gets substituted, even if the whole match is required.

Branches

It is possible to build a regular expression from two possible patterns, that will
match where either or both does. We use the "\|" operator for this: "abc\|def" will
match either "abc" or "def". This is the lowest precedence operator, so no parentheses are
necessary to group the two sides (but it can be used within a subexpression to make it
match either).

Concats

Concats are not really very useful, given the "\zs" and "\ze" match extent overriding
tokens. A concat is expressed as "abcdef\&abc", and it matches the input section
matched by the last subexpression, but only if the previous one(s) have already
matched at the same place. For example, "abc\&def" will never match (as "abc" and "def"
cannot appear in the same place). The same effect can be done with "abc\zedef".

Special characters

There are some special characters that must be written especially in a regular expression:
"\t" stands for the TAB character, "\e" for the ESC character, "\r" for the CR character
(not possible in ViEmu as Word interprets it as a paragraph terminator), and "\b" for the
BACKSPACE character. "\n" looks similar, but it isn't (see the next section).

7.12. Multi-line matching

All the elements we have seen involve only "regular" characters - thus, any regular expression
composed with the above elements will only match sequences within a single line. The regular
expression compiler accepts some tokens that allow matching line terminators, and when using
these, the matching engine will be able to match at end of line, advance to the first
character of the next line, and continue matching there.

Please note that line terminators are treated identically, no matter whether it is a Word document, a
UNIX-type text file (lines terminated with LF), an DOS/Window text file (terminated with CR-LF) or
even a Mac text file (CR). The actual original representation of the line terminator is not
checked at all.

The simplest character that causes this behavior is "\n" - this character matches and
consumes a line terminator, advancing to the next line. Thus, the regular expression "abc\ndef"
will match at a line which ends in "abc" and a where the next line starts as "def".

Another multi-line extension is the character classes in the form "\_x". All the character
classes described in section 7.7 can be given in this form, and this turns them into accepting
both their regular character sets, and the newline character.

Sets can also be made to accept newlines. There are two ways: either you include the "\n"
character within the set, or you start the set with the sequence "\_[" instead of the regular "[".

An example use of this sequence is to detect sequences of lines starting with the same word:
"^\s*\(\w\+\)\>.*\n\s*\1\>" will detect two lines in a row starting with the same word,
and "^\s*\(\w\+\)\>.*\(\n\s*\1\>.*\)\+" will match all the lines stating with the same word.
These expressions are simpler in 'verymagic' mode, but using magic mode is the most common way
(as 'verymagic' is vim-specific and not supported in vi).

7.13. vim regex features not supported by ViEmu

ViEmu implements most, but not all, features of vim regular expressions. vim regular
expressions are a superset of traditional vi regular expressions. These are the features
of vim regular expressions not implemented by ViEmu:

~ (match last :s substituted string)

\@>: which is a multi which does not retry after the first match is done

\@=: multi that turns the previous atom in a zero-width match

\@!: multi that matches with zero-width if the preceding atom does NOT match

\@<=: multi that causes first looking for the second part, then checks for the first

\@<!: multi that causes first looking for the second part, then checks that the first does NOT match!

^ and $ detected as "special" not only at pure regex start and end, but also at branch and
subexpression endpoints

\Z (ignore differences in unicode combining chars)

7.14. Detail of magic mode

This is the way each special character has to be written in each mode for it to be
interpreted for its special meaning:

meaning

verynomagic

nomagic

magic

verymagic

zero-width end-of-line

\$

$

$

$

zero-width start-of-line

\^

^

^

^

zero-width end-of-line

\.

\.

.

.

zero-or-more times the previous elem

\*

\*

*

*

one-or-more times the previous elem

\+

\+

\+

+

zero-or-one times the previous elem

\=

\=

\=

=

zero-or-one times the previous elem

\?

\?

\?

?

start of set definition

\[

\[

[

[

start of counted-repetitions token

\{

\{

\{

{

start of grouped subexpression

\(

\(

\(

(

end of grouped subexpression

\)

\)

\)

)

zero-width beginning of word

\<

\<

\<

<

zero-width end of word

\>

\>

\>

>

branch separator

\|

\|

\|

|

concat separator

\&

\&

\&

&

7.15. Operator precedence

These are the operators, in highest-to-lowest precedence order:

multis ('*', '\+', '\=', '\?' and '\{}'

concat separator ('\&')

branch separator ('\|')

Subexpression parentheses (both '\(' and '\%(') can be used to override this precedence.
For example, "\(abc\|def\)ghi" will match either "abcghi" or "defghi".

8. The ex command line

General

The ex command line is accessed by pressing ':' from normal or visual mode. It allows you to enter
commands known as 'ex' commands, which perform general functions as well as very powerful text editing
operations.

The first set of ex commands could be refered to as "environment" commands. They don't operate on
the contents of the edited file, but they provide a means to open new files, save them, navigate open
files, etc. They provide implementations which are sensible within the
Word/Outlook environment. A few of them accept parameters: :e[dit], :mac[ro], :vsc[md], :b[uffer] and :ta[g]. In this list, sequences
between square brackets ("[" and "]") are optional.

:new: brings up the "New File" dialog]

:q[uit]: (that is, the "uit" part is optional and ellidable) closes the current file and closes Word if there are no more documents opened

:qa[ll]: closes all open files

:wq or :x: saves and closes the current file

:e[dit]: brings up the File/Open dialog, or, if given an argument, tries to open that file

:w[rite]: saves the current file

:wa[ll]: saves all modified files

:sp[lit]: splits the current editing window (or closes the second view if it is already split)

:bd[elete]: closes the current file

:xa[ll] or :wqa[ll]: saves and closes all open files

:clo[se]: closes the current file, or window split

:f[ile]: shows information about the current file and cursor position in the status bar

:ls: shows the buffer list with their buffer numbers

:b[uffer] {N}: goes to buffer N (1-based)

:bn[ext] or :n[ext]: goes to next file in the buffer list

:bp[revious] or :N[ext]: goes to previous file in the buffer list

:ve[rsion]: shows the ViEmu version

Apart from these, ViEmu provides a fully functional subset consisting of the most important ex commands, which bring
a large part of vi/vim's raw text editing power to Word/Outlook. The general form of all ex commands is:

:[range]command[!]args

The range specifies on which lines the given command is to be applied.
It can take many different forms (see below).

The command is one of the ones listed below. Most commands can be abbreviated to a shorter form,
for example, substitute can be given as substitute, subst,
su or even just s (and all intermediates). Thus, it is often shown as
s[ubstitute].

The ! ("bang" or exclamation mark) alters the way the command works in a command-specific way. Not all
commands allow !. The description of its function is given with each command.

The arguments are command-specific, and their function is described with each command.

Core ex commands

:*map family of commands to map an input key sequence to another arbitrary sequence of keys

:*noremap family of commands for mapping w/o further mapping processing

:*unmap to remove mappings

:[range]d[elete] [x] [count] to delete (x is the register)

:[range]y[ank] [x] [count] to yank (x is the register)

:[range]j[oin] [!] to join the lines in the range, or default to the given line (or cursor line) and the next

:[line] pu[t] [!] [x] to paste after (!=before) the given address (x is the register)

:[range]co[py] [dest] to copy the lines in range to the destination address (:t is a synonim for this)

:[range]m[ove] [dest] to move the lines in range to the destination address

:[range]p[rint] [count] to print the lines (send them to the output window) (:P is a synonim for this)

:[range]nu[mber] [count] to print the lines (send them to the output window), w/line number (:# is a synonim for this)

:[range]s[ubstitute]/re/sub/[g] to substitute matches for the given regex with sub (do not give 'g' for only 1st match on each line)

:[range]g[lobal] [!]/re/cmd to run ':cmd' on all lines matching the given regex (! = *not* matching)

:[range]v[global] /re/cmd to run ':cmd' on all lines *not* matching the given regex

:delm[ark] {mark(s)} removes one or more marks (jumping to them will fail afterwards)

And this is a detailed explanation of each:

:set

ViEmu implements six vi/vim settings: ignorecase, smartcase, magic,
incsearch, hlsearch and gdefault, remap, wrapscan,
list, nrformats, timeout, timeoutlen.
It also implements two settings of its own, viundo and vaxesc (not used in ViEmu/Word&Outlook).
You can set them with a prependend 'no' as in vi/vim in order to turn them off, or with 'inv' to toggle them.
They allow the abbreviations
ic for "ignorecase", scs for "smartcase", ma for "magic",
is for "incsearch", hls for "hlsearch", gd for "gdefault", rem for "remap",
ws for "wrapscan", nf for "nrformats, to for "timeout" and tm for "timeoutlen".

"ignorecase" governs whether searches take into account the case of text. It applies both to general character matches,
as well as \1..\9 subexpression repetition and sets. As in vim, character classes do not honor this flag.

"smartcase" is only taken into account when "ignorecase" is on. It makes "ignorecase" non-functional if the input
search pattern contains any uppercase characters. It allows you to have "ignorecase" on, and force case-checking by just
specifying some of the search pattern characters in uppercase. If you need to look for a pattern which is composed only of
lowercase characters and force case checking, you can use the "\C" flag anywhere in the sequence (such as "/for\C") to force
the search to check the case.

"incsearch" controls whether the cursor/selection are used to show the target of the search while it is being typed.

"hlsearch" enables highlighting of all matches of the last search performed in the current buffer.

"gdefault" toggles the default behavior of the :s command, making it replace all matches in a line by default,
and making the 'g' flag limit the substitution to the first match only.

"nrformats" controls the formats supported by the Ctrl-A/Ctrl-X increment/decrement commands. It can contain any combination of "octal", "hex" and "alpha", separated by commas.
Default is "octal,hex". Increment/decrement will recognize decimal, and the selected types - octal numbers must start with "0", hexadecimal ones with "0x",
and alpha operates on single letters.

"timeout" controls whether a timeout triggers interpreting ambiguous input, in the presence of multiple key chord mapping. If set,
the partial input will be processed without the mapping after the period specified by "timeoutlen". Default is active.

"timeoutlen" specifies the time after which the resolution processed by "timeout" is performed, in milliseconds. Default is 1000, for a one-second wait.

"viundo" activates a basic simulation of vi's one-item-only undo queue, by actually issuing a redo when an undo
is done for the second time in a row.

"vaxesc" doesn't do anything in ViEmu/Word and Outlook.

:d[elete]

:[range]d[elete] [x] [count]

:d deletes the lines indicated by the given range. The range defaults to the current line. 'x' represents a register
name to which to copy the text before deleting it. If a count is given, count lines are deleted starting with
the last line in the range. Thus, :10d a 5"copies lines 10 to 14 to the "a" register and then deletes them
(you can paste them back with "ap).

:y[ank]

:[range]y[ank] [x] [count]

It works the same way as :d[elete], but doesn't delete the text (it copies it to the given register)

:j[oin]

:[range]j[oin][!]

:j[oin] joins together the lines in the given range, forming a single line. The form with "!" doesn't add
or remove any whitespace, while the regular form substitutes all the leading whitespace in joined
lines by a single space (unlike vim, it doesn't remove extra whitespace from the tail of joined-to
lines).

If no range is given, the default range is (current,current+1), joining the line below to the one
where the cursor is. If a single line number is given, the default end of range is the line after that one.

:pu[t]

:[line]pu[t][!] [x]

Pastes the text from register x after the given line. Zero is a valid line number here, and pasting
after it results in pasting before the first line. If ! is given, it pastes before the given line.

The contents are always pasted in linewise mode, no matter what mode the original text was yanked in.

:co[py] / :t

:[range]co[py] dest

It copies the lines in the range given to just below the given destination line. Zero is a valid
line number in this context, so that lines are copied to the beginning of the file. All line
designators used in ranges work as the destination argument ('$', searches, etc...).

:t is just a synonym of :co[py].

:m[ove]

:[range]m[ove] dest

It copies the lines in the range given to just below the given destination line,
and deletes the original text from its current location. Zero is a valid
line number in this context, so that lines are moved to the beginning of the file. All line
designators used in ranges work as the destination argument ('$', searches, etc...).

:p[rint] / :# / :nu[mber] / :P[rint]

:[range]p[rint] [count]

:[range]P[rint] [count]

:[range]nu[mber] [count]

:[range]# [count]

All these commands send the lines given by the range to the "ViEmu" tab in the output window.
:nu[mber] and :# prepend them with the line number. If a count is given, it will print count lines
starting with the last line in the range.

:g[lobal]

:[range]g[lobal][!]/regex/command

:g looks for matches of the given regular expression on all lines of the file,
sets the cursor to each line that matches in turn, and then runs the given ex
command. The command internally first scans the whole file for matches,
sets a mark on each line that matches, and then runs the command once for every
mark (after setting the cursor position to that line). Given that marks positions
are properly updated for every modification done by the command, it can
operate properly for many editing commands.

If ! is given, the command is run for lines that don't match
the given regular expression. This is the same as using the :v[global] command below.

For example, :g/^/m0 is the idiomatic way in vi/vim to invert a file:
'^' is the beginning of line indicator, which by definition matches on every line.
The "m0" command moves the line to the top of the file. Executing this command for all
lines in order results in the file having the order of all of its lines reversed.

Another common idiom is :g/^$/d to delete all lines with no characters
on them (if end-of-line matches right after beginning-of-line, it's because there are
no characters in the line!). If you want to delete all lines with only whitespace,
you can use :g/^\s*$/d which allows any number of whitespace
characters but nothing else.

Anecdotally, this command is the source of the name of the popular Unix
grep command: :g/re/p, where "re" stands for
"regular expression", is the vi way to print out all lines matching the given regular
expression, which is what grep does.

:v[global]

:[range]v[global]/regex/command

This is the same as :g[lobal]!, that is, it executes the command on lines not
matching the given regular expression.

:s[ubstitute]

:[range]s[ubstitute]/regex/replacement/[g]

Together with :g, this is the most powerful ex command. ViEmu only supports the 'g' ('global')
option, where vi/vim support some additional ones.

The command searches for matches of the given regular expression in the given range. It then
replaces the matched text by the given replacement string. If the 'g' option is not given, a single match
is looked for and operated on per line. If 'g' is given, multiple matches per line are searched for
and acted on (the text inserted as the result of the substitution is not scanned though). The 'gdefault'
preference reverses the default behavior and the meaning of the 'g' flag (see :set).

The replacement string treats some characters and sequences specially. The character '&'
is substituted with the matched text before inserting it (use '\&' if magic is not set). The
sequences \1 to \9 are substituted by the corresponding matched subexpression before inserting them.
'\r' inserts a line break, allowing multiline replacements.

Other characters can be used instead of '/' as delimiters: :s,a,b,g is the same
as :s/a/b/g. vim only accepts non-alphanumeric characters, while ViEmu accepts any
character (but a space is needed before the first one if it is an alphanumeric character).

As an example, :%s/\s\+$// will delete trailing whitespace on all lines.

:&

:[range]&[g]

Repeats the last :s, overriding the original 'g' option with the given one, on the given range.

<fromkeys> can be either a single key or a sequence of keys. The different versions of the mapping command apply the mapping in different contexts.
Both <fromkeys> and <tokeys> can use ASCII characters directly, or key 'names' from the following
list:

Use a backslash ('\') to remove the special meaning of < or >. Use "\\" to refer to the backslash key itself.

You can add modifiers inside the angle brackets: <C-F2> means control + F2, <A-S-Up> means Alt + Shift + Up.
The Shift modifier is ignored for ASCII character mappings, as its meaning is included in the ASCII code.

These are the different contexts with their meanings:

normal, visual, insert: refer to each of the modes.

command-line: refers to command line editing, both for '/' searches and ':' ex commands.

operator: refers to the situation of ViEmu being waiting for the motion after an operator command

language: this refers to insert mode, command line editing, or the part of commands that is composed
of content-characters (the argument to the f/F/t/T motions, the argument of 'r', etc...)

The command applies the mapping in the given context. Any entering of the sequence 'fromkeys' given in the left hand side will be substituted
by the 'tokeys' list of keys on the right hand side. These keypresses will further be scanned for other mappings (see :*noremap).
Raw :map applies the mapping in all normal, visual and operator-pending contexts. :map! applies it to insert mode and
command line editing mode. :lmap applies it to insert, command line editing and language-arg contexts.

For a multiple-key-chord mapping (:nmap c_ ct_), if only part of the input has been typed (say, 'c'), ViEmu will wait until the next
key disambiguates whether the mapping has to be applied or not. ViEmu by default waits for one second, and if no other key is received,
it triggers processing the received keys normally. See the description of the "timeout" and "timeoutlen" :set options for details.

:*unm[ap] family

These commands remove the sequence <keys> from ViEmu's mapping table for the given context(s), making it
return to its regular behavior. If the mapping applied to several context, it is left active for
the rest of the contexts.

:delm[ark] {marks}

Removes the given marks, which can be space separated or not, and global (uppercase) or local (lowercase).

Ex ranges

All ranges are composed of a sequence of line specifiers separated by ',' or ';'.
If more than two line specifiers are given, only the last two are used. Separating with
semicolon makes the next line specifier start from where the previous one left, which
is important in relative line specifiers.

The simplest line specifiers are just line numbers (1-based). For example, the range "1,100"
represents the first 100 lines. Thus, ":1,100d" will erase the first 100 lines in the file.

There are two simple special line specifiers: '$' stands for the last line in the file, and '.'
stands for the current line. Thus, ":.,$d" will erase all lines from the current one to the end of file.

As a special case, '%' is itself a shortcut for '1,$', thus representing the whole file. It
is quite common to use '%' with the :s command to perform a substitution in the whole file:
":%s/one/two" will replace the first appearance of "one" by "two" on all lines (append "/g" to
do it on all instances).

Marks can also be used as line specifiers: use a quote followed by the mark character to
represent the line where the mark is. The ''', '.', '<' and '>' special marks can also be
used. Actually, when you press ':' in visual mode, the ex command line is started with ":'<,'>",
which represents the currently selected visual range of lines. This range can also be specially
specified as "*", in the same vein as "%".

Finally, lines can also be specified by forward or backward searches. Use "/re/" to refer to
the first match of "re" from the start position (either the cursor position, or the previous
range element if separated with ';'). Use "?re?" to find backwards. As an example, ":/abc/;/def/d"
will first look for "abc" starting from the cursor position, then look for "def" starting
from *that* line, and then delete those lines and all in between.

vi and vim also allow appending "+N" or "-N" to any line specifier, but ViEmu doesn't yet
implement this.

If a single line is specified for a range, the implicit range depends on the command - see
the descriptions above. Actually, only the :j command understands the implicit range to be
that line and the next, all other commands understand the one-line range implied
by using the given line as both start and end of range.

Initialization file: .viemuwrc

When ViEmu is started by Word/Outlook add-in loading machinery, it scans certain folders
for a file named '.viemuwrc' or '_viemuwrc' (in that order). The folders checked are, in this order:
(1) the path indicated by the HOMEDRIVE/HOMEPATH environment variables, (2) the path indicated by
the HOME environment variable, and (3) ViEmu's installation folder (typically 'C:\Program Files\ViEmu').
If it is found, the file is loaded and its contents executed as ex commands (no colons are necessary
before each line). Given that these commands are run in a context with no 'current file', the only
commands that make sense are :set, :*map and :*unmap. Typically, this file is used to set options
that are to be applied always. Within ViEmu, preferences as specified in Tools|Options|ViEmu are loaded
before loading .viemuwrc, so options set in .viemuwrc overwrite and take precedence over
regular settings.

If an error is found in any line, the file name and line number will be output to the Output
window, under the ViEmu tab.

9. Differences with vi and vim

Although ViEmu is designed to provide the most comfortable environment to both vi and vim users,
there are many differences between ViEmu and any of them. For one, there are parts of vi and vim
which are not (yet) emulated by ViEmu. On the other hand, there are some things that I chose to
implement differently because they made more sense within Word/Outlook
(a foreign environment to vi/vim editing, and one which imposes a different view on many aspects).
This section details both the intended differences, and the yet-to-be-implemented features of vi/vim.

Things emulated slightly differently (for better integration)

If you find that any of these is troublesome,
please tell us so that they can
be addressed.

Default yank/del/paste buffer can be configured to be the Windows clipboard
(special register "*" in vim)

C-u, C-d, C-f and C-b are emulated as motions. This means they can be used to
extend the current selection or as operator command arguments. There doesn't
seem to be any loss in doing this way, there are definite advantages, and it't
not easy to understand why they are not motions in vim - except C-u and C-d,
which act as motions for visual selection extensions, but not for operator
command arguments.

Behavior when pasting over a visual-mode selection is slightly different from
vim when the pasted register and the selected ranges are of different types. I
think ViEmu's model makes a bit more sense, although none of the two models are
a very useful editing operation.

When repeating with '.' a command that operated on a visual motion, if the
range was charwise, it is simulated keeping the line and column offset, in
place of per character count. This usually makes more sense.

Multi-line input (as invoked with 'I','A', 'C' or 'c' from visual-block
selection mode) in vim doesn't work if deleting characters, joining lines or
splitting them. ViEmu supports this in most cases (where it makes sense).

Multi-line input supports counts for 'c' and 'C' commands as well, not just for
'I' and 'A'

"Inner selections" by pairs of delimiter characters ("ib"/"i)"/"i(",
"iB"/"i}"/"i{", "i>"/"i<", "i["/"i]") move the last character to the end
of the previous line when the closing character is the first non-whitespace in
its line. This is done by vim only for curly-brace blocks ("iB"/"i}"/"i{"), but
not for the rest. It aids in being able to indent material between delimiters,
and even if does not usually appear in C or C-like languages, it is equally useful
for the rest of the delimiter pairs.

Limitations / things not emulated

I definitely intend to address these limitations in further releases of ViEmu.
Please tell me which features
you are more interested in.

vi-style abbreviations are not supported.

[[,[],][,]] only search braces in column 0, not section boundaries as defined
by form-feed characters.

Sentence delimiters in ViEmu are '.', '!' or '?' *strictly* followed by either
newline, space, tab, ')', ']', '"' or '"', apart from completely empty lines.
vim supports a bit more flexibility.

Block selections with a non-fixed-width font don't represent well when standard selection
is used represent the selection. There are other inconsistencies here as well in the
presence of folds or word wrapping. Using the custom-text-markers selection is recommended.

"Virtual edit", that is, moving the cursor beyond end of line, is not
supported.

In overtype mode (such as with the R command), BACKSPACE does not restore the
last character as vim, it erases it. This is required due to interactions with
the standard Word editing model.

Numbered registers "0 to "9 do not "roll" like in vim, they are regular
registers.

Pasting over a visually selected region (p or P in VISUAL mode) does not copy
the selection into any register

Cursor positions after undo/redo are not the same as in vi/vim. This is due to
the standard undo mechanism.

ViEmu has only been limitedly tested with non-single-byte or non-left-to-right codepages. There are
provisions in the code for these issues, but they are untested and unsupported as
of now. No provisions have been made either for right-to-left or bidirectional
text. Supporting these features is planned for future versions, and we would be
glad to hear from you about how it
works for you in this respect.

10. Support

Support is available via e-mail and on the support forums. You can write to
support@symnum.com for any
question. All inquiries are answered within two business days,
usually much faster.

The support forums are available at www.viemu.com/forums.
Apart from support questions, frequent updated builds are announced there.

I try to address as promptly as possible any questions with installation or ViEmu,
esp. fixing bugs in the software.

When reporting a problem, please try to provide general information about your system
(OS, version of Word/Outlook you are using, other installed add-ins, etc...),
and as much information as you can about the context in which the problem
appeared (last action performed, state of the sytem, etc...).

If you are not yet a registered customer, but you have found some problem installing
or using the evaluation version of ViEmu, we will be glad to answer any question
you send to the above support address.

11. Change log

ViEmu 2.5 (April 20 2010):

Version 2.5 consolidates all 1.5.x improvements, brings important new features, and implements the new Symnum licensing system.
The jump from version 1.5 to 2.5 is in order to sync it with ViEmu/VS and ViEmu/SQL Server.

2.2.2:

Better i' a' i" a" logic

2.2.3:

Improved pasting logic

2.2.6:

Minor fixes in installer

Removed potential race condition

2.2.8:

Fixes "100%" motion (including precise {n}% vim emulation)

2.2.9:

Fixed {n}| motion behavior (was off by one)

:ern[ext]/:erp[rev] commands to navigate errors

New EXE-based installer, clearer, and better compatibility with Vista/Win7 UAC

"Desired cursor column" is now updated after repeating input, as in vi/vim

ViEmu 1.1 (August 18th, 2005):

Bugs fixed:

"Find in Files" would often freeze when reaching a file edited with ViEmu

Text input during macro recording was not properly re-input when playing back

A '.' command involving line entry in indented lines at end of file did not work well

Deleting a character range in the last line moved the cursor to column zero

The count in the 's' command applied to the input repetitions, should apply to the # of chars erased

'/' without arguments didn't do anything, now it properly repeats the last search forward

'o' or 'O' with a count did not repeat the NewLine operation, only the text input

New features added:

ViEmu now intercepts all text editing windows, this provides for better integration in all cases

Ctrl-SPACE and Ctrl-Shift-SPACE did not bring up autocompletion/method info in insert mode - now
insert mode is quite similar to regular Visual Studio editing and supports these as well as many
other shortcuts

Mark positions and position history (Ctrl-I/Ctrl-O) are now correctly updated during editing,
so they remain tied to the original text where they were set

ViEmu now hooks Visual Studio's editor in a way that allows proper compatibility with other
editor-enhancement add-ins