ViEmu: vi/vim emulation for Microsoft SQL Server

1. General

ViEmu is a an add-in for Microsoft SQL Server 2005, 2008, 2012, 2014 & 2016, which enables vi/vim-like editing inside SQL Server Management Studio. Based in ViEmu 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, hlsearch search highlighting, and many other features.

ViEmu 2.0, improved in 2.1 and 2.2, provided a much more advanced vi/vim emulator and much better integration: colored text markers to implement hlsearch, much better emulation of vim's visual modes, better repetition of input, faithful emulation of undo-grouping, full wordwrapping support, automatic removal and management of clashing keybindings, and many other features.

ViEmu 2.5, brought 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.

ViEmu 3.0 brought even more features to ViEmu: the much requested 'c' switch for the search and replace command which displays a confirmation dialog, support for the 'i' (case insensitive) and 'I' (case sensitive) switches also for the search and replace command, Ctrl-N/Ctrl-P in insert mode to navigate through a generated list of matches for the partially written word, and support for SQL Server 2012.

ViEmu 3.5 added more features such as it/at XML tag text object motions, and unified of version numbers with all other ViEmu editions.

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

I hope you will find ViEmu useful!

2. Integration with Management Studio

3. ViEmu preferences

3.1. Main preferences page

1. Remove the offending key from the list of scanned keys
2. Click on 'Apply' to save the setting
3. Click on the 'Restore' button to restore the original keybindings
4. Now, the previously offending keybinding won't appear in the list on the right as it is no longer considered
5. Finally, click on the 'Save and Remove' button to remove these keybindings and remember them for later restoring

4. The status bar

5. Miscellaneous integration info

6. The vi/vim input model

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 SQL Server Management Studio interprets it as a line 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 UNIX-type file (lines terminated with LF), an DOS/Window file (terminated with CR-LF) or even a Mac file (CR). The actual original representation of the line terminator is not checked at all, and SQL Server Management Studio even allows different terminators to be used in different lines of the same file (not that it is healthy).

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!
• \%^ (beg-of-file), \%$ (end-of-file), \%# (cursor-pos), \%23l (specific line), \%23c (col) and \%23v (vcol)
• \%[: optional tail ("wh\%[atever]")
• vim detects & prevents "multis" following possibly empty matches (such as \(\)* or even \zs*)
• ^ 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:

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 SQL Server Management Studio 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 [not in SQL Server Management Studio]
• :q[uit]: (that is, the "uit" part is optional and ellidable) closes the current file
• :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
• :bui[ld]: starts a build of the current solution
• :prb[uild]: starts a build of the current project
• :comp[ile]: starts a compilation of the current file
• :deb[ug]: starts a debug session of the current solution
• :cn[ext]: jumps to next compilation error
• :cp[rev]: jumps to previous compilation error
• :ern[ext]: jumps to next error
• :erp[rev]: jumps to previous error
• :ta[g]: jumps to the definition of the identifier under the cursor
• :fd: brings up the standard Find dialog
• :mac[ro]: executes the given macro. Full scope needed (eg, ":macro MyMacros.Module1.myMacro")
• :vsc[md]: execute the environment command given as an argument, for example, View.SolutionExplorer
• :run: execute the current SQL Query
• :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 SQL Server Management Studio. 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

This is the list of the core ex commands ViEmu implements:

• :set param - basic implementation allowing [no]ig[norecase]/[no]ic, [no]sm[artcase]/[no]sc, [no]ma[gic], and [no]viu[ndo]
• :*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/[gciI] 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
• :[range]> indents all lines in the range
• :[range]< unindents all lines in the range
• :delm[ark] {mark(s)} removes one or more marks (jumping to them will fail afterwards)
• :noh[lsearch] disables hlsearch highlighting until next search
• :u[ndo] undoes the last action or action group
• :red[o] redoes the last undone action or action group

And this is a detailed explanation of each:

:set

ViEmu implements several vi/vim settings: ignorecase, smartcase, magic, incsearch, hlsearch, gdefault, remap, wrapscan, list, nrformats, timeout, timeoutlen. It also implements two settings of its own, viundo and vaxesc (not used in SQL Server). You can set the boolean ones 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".

":set" alone or ":set all" shows the current state of all settings.

"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.

"remap" enables recursively applying mappings to keys gotten from a remapping.

"wrapscan" enables continuing a search from the beginning of the file when the end is reached (and viceversa for backwards searches).

"list" controls the visibility whitespace and tab characters.

"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 for SQL Server.

: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 the regular expression field is empty (:g//...), the last search string will be used.

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/[gciI]

Together with :g, this is the most powerful ex command. ViEmu supports the 'g' ('global'), 'c' (ask for confirmation), 'i' (case insensitive) and 'I' (case sensitive) options, 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).

If the regular expression field is empty (:s//...), the last search string will be used.

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. \u and \l make the next character uppercase/lowercase. \U and \L turn on uppercase/lowercase conversion for the rest of the string. \e or \E stop this behavior.

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.

:*map family

  :map  <fromkeys> <tokeys>
  :map! <fromkeys> <tokeys>
  :nmap <fromkeys> <tokeys>
  :vmap <fromkeys> <tokeys>
  :omap <fromkeys> <tokeys>
  :imap <fromkeys> <tokeys>
  :lmap <fromkeys> <tokeys>
  :cmap <fromkeys> <tokeys>

<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:

<F1> to <F12>, <Up>, <Down>, <Left>, <Right>, <Home>, <End>, <PageUp>, <PageDown>, <Delete>, <Insert>, <BS> = <Backspace>, <CR> = <Return> = <Enter>, <Space>, <Bslash>, <Bar>, <Esc> <Escape>, <lt>, <gt>, and <Tab>

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.

:*noremap family

  :noremap  <fromkeys> <tokeys>
  :noremap! <fromkeys> <tokeys>
  :nnoremap <fromkeys> <tokeys>
  :vnoremap <fromkeys> <tokeys>
  :onoremap <fromkeys> <tokeys>
  :inoremap <fromkeys> <tokeys>
  :lnoremap <fromkeys> <tokeys>
  :cnoremap <fromkeys> <tokeys>

:*unm[ap] family

  :unmap  <keys>
  :unmap! <keys>
  :nunmap <keys>
  :vunmap <keys>
  :ounmap <keys>
  :iunmap <keys>
  :lunmap <keys>
  :cunmap <keys>

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.

You can add as many '+N' or '-N' modifiers, where N is a number, to each specifier, modifying the base line it refers to. Typing "N:" from normal mode enters ex command line editing with ":.,.+{N-1}" as a prefix, resulting in a range that specifies N lines starting at the current one.

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: .viemurc

When ViEmu is started by the SQL Server Management Studio enviornment, it scans certain folders for a file named '.viemurc' or '_viemurc' (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 .viemurc, so options set in .viemurc 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.

Empty lines are skipped, and comments can be inserted in the file by inserting a " to begin the line

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 SQL Server Management Studio (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)

10. Support

11. Change log

ViEmu 3.7.5 (January 2017):

• Added support for Visual Studio 2017 RC and SQL Server 2016 version 16.5 (new installer was required)
• Improved support for high DPI displays in ViEmu for Word and Outlook

ViEmu 3.7.1 (December 2016):

• Added support for Xcode 8.2

ViEmu 3.7 (November 2016):

• Added vi/vim search offset support: /something/+1, /something/;/else/e+2, etc...
• Added support for SQL Server 2016, Xcode 8, improved Visual Assist compatibility

ViEmu 3.6 (August 2015):

• Enhanced the % motion to fully emulate vim: added suppport for navigating #if/#else/#endif and /* */ C-comments
• Added support for Visual Studio 2015 and Xcode 7

ViEmu 3.5 (June 2015):

• Added support for it/at XML-style tag objects
• Unified back-end build system enabling full new releases of all ViEmu versions

ViEmu 3.0.1 for SQL Server (June 19, 2012):

• Added support for the 'c', 'i' and 'I' options of the search and replace command.
• Added file-scan autocompletion support, with Ctrl-N/Ctrl-P keys in insert mode.
• Support for SQL Server 2012.
• Added setting in ViEmu/SQL Server 2005 & 2008 to apply a "fix-up" so that Ctrl-U will allow scrolling.

ViEmu 2.5 (April 20 2010):

• Better i' a' i" a" logic

• Improved pasting logic

• Fixed bug that could cause a crash when editing HTML

• Minor fixes in installer
• Removed potential race condition

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

• 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

• Implemented multiple-key chord mappings (:nnoremap end $), with ambiguity support, timeout, timeoutlen, etc..
• Implemented Ctrl-A/Ctrl-X command to increment/decrement numbers (or letters), also with 'nrformats' variable
• Implemented insert mode Ctrl-Y/Ctrl-E to copy character from line above/below
• Fixed bug: right after 'g' or 'z', normal mode mappings are not applied (technically it's in normal mode, but it's more like a parsing sub-mode)
• Fixed bug: made searching backwards actually work with \zs somewhere other than at the start
• Fixed bug: removed buffer from buflist (:ls) after closing it with :q, same as was done before with :bd
• Fixed bug: K did weird things in visual mode (moved to top), fixed (now it does nothing)
• Fixed bug: an empty o<esc> would not set the `. mark, now it does
• New licensing system

ViEmu 2.2 for SQL Server 2005 & 2008 Management Studio (July 14th, 2008):

• Removed the warning when you try to paste in a read-only buffer
• Added user setting to remove "Read-only op" warning
• Removed dialog box when trying to paste in a readonly dialog
• :n, :N as synonims of :bn, :bp
• Made 'a or `a or :13 open folds
• Fixed the "ct<space>" problem when <space> is :mapped to something (changed order when determining current mappin context, lang-arg must come before op-arg)
• Fixed 'zz' problem with wordwrap
• Fixed crash when searching for "\zs*" due to the 'incsearch' feature
• Made Ctrl-U in cmdline mode delete back to the start
• Made Ctrl-W in cmdline mode delete a word
• Made Ctrl-U in insert mode delete back to the point of insertion
• Made Ctrl-W in insert mode delete a word
• Removed "--NORMAL--" and similar modeline info when typing a search or an ex command
• Better emulation of vim's "vi undo mode"
• Addressed i_Ctrl-D differences with vim

• :s options \u \U \l \L didn't work with \1 type submatches, fixed
• Fixed crash when setting a number mark (global) (ie, m3)
• Global marks were not edit-updated
• Undo undid too much with external VS actions
• Made :s show a message if nothing is found
• Made // and ?? shortcuts repeat last search

• Updated installer to work with SQL Server 2008 ("Katmai") CTPs and final build

• Fixed ViEmu/SQL Installer for Vista systems (it would sometimes fail)

• Added :ve[rsion] command to show the version and web address for ViEmu
• vj$:s/.../ woudn't work, said 'mark not set'
• Fixed wrapscan fails when searching exactly from beginning-of-file and end-of-file
• Made <c-v>i} always extend selection by changing cursor sanitization to allow EOL in non-chars visual modes
• Made the fold command create the outlining session if it doesn't exist
• Made zf move the cursor to the first char, regions weren't always being folded in VS2k5+
• Made :omap w iw work fine and not screw up "diw", "daw"... by applying it only at the first char after an op (like vim)
• Made gS only effect if last command in macro (or if stand-alone)
• Implemented gt/gT to go to next/prev buffer

• Fixed bufpos remembering when doing gt/gT/:bn/:bp
• Implemented gp/gP to paste and leave the cursor after the pasted text
• Implemented i', i", a', a" vim7 text-object motions

ViEmu 2.1 for SQL Server Management Studio (February 26th, 2007)

• :noh[lsearch] implemented
• hlsearch setting wasn't honored on startup, even if it was shown fine in Tools|Options|Viemu
• The desired-cursor-col was not reset after moving the cursor by left-clicking
• :set gdefault would not work in .viemurc
• The \| operator in regular expressions didn't work fine (would only match the second branch)
• Keyboard management should now support the Japanese version of Visual Studio
• Ctrl-T/Ctrl-D in "virtual space" work fine (after o/O with autoindent)
• :bd now removes the buffer from the buffer list (it also closes the file if it's the current file, not if it isn't)
• <c-t> now invokes View.PopBrowseContext (poor man's tag stack pop)
• :set [no]remap implemented to disable all recursive mapping
• infinite mapping loops detected & cut (eg, :map n l and :map l n)
• visual block done by ^Q j $ now extends to the $ of each line
• 'A' on a visual block extended to end of line ($) wouldn't work
• dd on a single-line file (or dG from the 1st line in any file) would leave a dangling line, fixed
• Special marks '[, '] (last pasted/changed/yanked/etc... range) and '^ (last insert pos) added
• Added gi command, to go into insert mode at the last insert position
• Proper keybinding management in German Visual Studio
• Command line space much larger (it was read & processed, but not properly displayed)
• Yanking of column blocks with empty lines fixed
• Playing a macro from an empty register would crash VS (@a)

• Special marks '[, '] and '^, introduced in 2.0.33, no longer cause the insertion of VS marks when the relevant option is selected in Tools|Options|ViEmu.
• Crash when yanking/deleting a $-extended characterwise block fixed. This is after having added proper $-extended column block handling back in 2.0.33.
• AltGr keys in international keyboards (Swedish, Spanish, etc...) didn't work right in normal mode. Esp. the '@' command (AltGr-2).
• Changed the first-time keybinding removal logic so that it won't remove extra standard keybindings (backspace, ...)
• Made Ctrl-[ in international keyboards where '[' is not on the same key as on the US keyboard work as Esc again
• Fixed the '%' motion to start checking at the last character is the cursor is beyond the end of line (as vim)
• Some remaining problems of AltGr key combinations fixed for international keyboard layouts (not repeating AltGr characters with '.')
• Cursor position was not restored properly after many operations (dd, r*, etc...)
• Pasting over a linewise visual selection at end-of-file didn't work well
• Editing a long command line could result into a crash (only actually likely in versions before 2.0.33, where the buffer was small)
• '.' would stop working properly for input repetition after switching back and forth between two split views of the same file
• Crash that happened when exiting Visual Studio if no ViEmu-subclassed window had been actually used.
• Tabify/Untabify commands under Edit|Advanced wouldn't work
• gu/gU/g~ could get into an infinite loop when modifying lines with hard tabs while using soft tabs (or viceversa)
• Shift-Tab in insert mode fixed so that it does its usual VS operation, that is, it unindents the line and cursor position if the cursor is anywhere in the leading whitespace in the line (else it does nothing).
• :g and :s with use (when given an empty regex) and modify (in other cases) the 'last-search-string' as vi/vim, the same value used by n/N to repeat the last search
• Implemented :> and :< ex commands for indenting/unindenting a range of lines
• Implemented ":set [no]list" option, it toggles Visual Studio's "View Whitespace" setting
• Implemented ":set [no]wrapscan" (or ":set [no]ws") option, it toggles wrap-around behavior for searches
• The "Use VS Selection for visual mode" and "Windows-style word-wrap navigation" settings weren't honored on startup. They were persisted and read properly, and they'd make effect from the settings UI, but not when starting up VS again.
• Experimental support for CUA-style selection (Shift+Arrow Keys or Navigation Keys)
• Pasting a block at the end of the file would send the cursor up to the top of the file
• Fixed "//<return>" from creating a slow editing experience because of invisible zero-width markers inserted in between every two characters
• Vista compatibility
• Fixed problems when using 'r' in a $-extended visual selection
• Fixed highlighting of block visual selection when there were hard tabs in a line

• Motions i or a followed by one of {}<>[]bB now are adaptive linewise/charwise, as in vim
• Ctrl-] followed by Ctrl-O didn't return to the point before Ctrl-], but to the one before that (it failed only in intra-file jumps)
• When searching with '*' or '#', \<token\> is now added to user-typed search history (you can do /<up> and they'll be there)
• Fixed bug in "single-line" files (cursor doesn't move) - it's a VS.NET 2003 bug, but ViEmu made it more apparent
• Implemented ':set'/':set all' to show all the current settings
• The cursor sometimes wouldn't properly have its block shape since the first moment (hopefully fixed)

• gI (input at "hard" beginning-of-line - column 0) implemented
• The '[' character was not allowed in sets in regular expressions ("[[abc]" means any of a, b, c and '[')
• Fixed repetition with '.' of input including high-ascii characters (>127)
• ViEmu/VS 2.0.52 had debug logging enabled by default

• v$ wasn't represented well when using VS selection for visual mode
• ESC now removes the status message in normal mode
• InternalUndoGroup() improved to obtain better performance (only slowed down in some installations)
• Resharper compatibility extended to Resharper 2.5
• Pasting a multiline block in a read-only file will now only warn once
• EULA updated to reflect the per-user license type (you could stay with the previous license, but this is just less restrictive)
• One installer path had a double backslash, it could cause problems in some installations
• EULA updated to reflect the per-user license type (you could stay with the previous license, but this is just less restrictive)
• :run command to execute the current SQL query

• Tilde key didn't work in swedish keyboard
• 5:s syntax and offset-ranges (:.,.+4s/...)
• Uppercase operators in :s subst string (\u \U \l \L \e \E)
• gd to go to local definition
• :u[ndo] and :red[o]
• " comments allowed in .viemurc
• 'v' in visual-chars, or 'V' in visual-lines... now exit visual mode
• HLSearch calculation made incremental, huge boost to the performance of hlsearch with large files
• Paste auto-reindent (]p)
• Searching with wrapscan doesn't enter folded #regions or outline folds
• IME reset when pressing ESC (useful when using Japanese and other Far East languages)
• /;<cr>i<cr> failed, second <cr> didn't work (ECMD_RETURN was cached disabled)
• Force undo grouping to be cut on buffer change (same as vim)

• :bd wouldn't work in the first buffer (All)
• :bd wouldn't work after closing a buffer with :bd and reopening it, if no other buffer got the focus in between (All)
• Find in Files could sometimes freeze if hlsearch was enabled (VS+SQL)
• The return key wouldn't work in the first opened buffer if Visual Assist is installed (VS)

ViEmu 2.0 for SQL Server Management Studio (September 25th, 2006)

ViEmu 2.0 for Visual Studio (September 11th, 2006):

• hlsearch
• Proper vim-like visual area representation
• Proper undo-grouping of operations (cw...)
• Proper Intellisense-autocompleted input repetition
• Automatic VS keybinding management
• Advanced mapping support (":cmap <c-n> <down>", ":map \\ /xkz<esc>"...)
• Buffer number commands - :ls, :b[uffer] <n>, :bn[ext]/:bp[revious] with these numbers
• Proper wordwrapping support, better and faster folding support
• Better incremental search (works also in visual mode)
• Macros stored in regular registers (use qa to record a macro and paste the contents with "ap)
• a..z marks local and A..Z global
• Proper autoindent when repeating input
• Cursor kept on screen in <c-e>/<c-y>
• Proper <c-f>/<c-b>/<c-d>/<c-u> which always scroll
• Proper iw/iW/ib/iB/i)/i}/i>/i] and a*... emulation
• Proper block selections in the presence of folds/wordwrapping
• 'o' command in visual mode
• :delmark command
• :xa[ll] and :wqa[ll] command
• :vsc[md] command
• Count support for the | motion

ViEmu 1.4 (November 25th, 2005):

• Visual Studio 2005 support
• ":wa[ll]" to write all files
• "gf" to open the file under the cursor
• "gq" operator to reformat code (via VS's autoformatting mechanism)
• "=" operator (same as gq)
• "|" motion to go to beg-of-line (same as '0')
• "%" allowed in non-pair characters - it scans for first one, then jumps from that one
• Ctrl-R recalls the contents of a register at the command line or in insert mode (as in vim)
• :macro command implemented: it allows running a Visual Studio macro from the ex command line

• 'yy' doesn't move the cursor to the beginning of the line any more (similar with other motions for yank)
• The 'immediate' command window and the 'find results' windows are no longer overtaken by ViEmu
• The cursor now gains block shape as soon as a window is open

• Mouse selection after end-of-line now works fine
• ZZ command implemented (same as :wq, save and quit)
• Visual Studio's messages on the status bar aren't overridden so often
• No querying about "backwards range given" when a visual selection is made upwards and an ex command is applied over that
• /<ENTER> and ?<ENTER> now properly repeat the last search (was broken in 1.3)
• Cursor position after linewise paste is now correct

• New settings: 'smartcase' and 'remove-vs2005-readonly-warning'
• MessageBoxes from ex command errors converted to status bar messages
• 'N lines yanked'/'N more lines' messages for yank/paste commands
• :set [no]viu[ndo] to revert to single-undo as in the original vi
• Ctrl-HOME/Ctrl-END now work.
• */# now act as if 'smartcase' weren't set, as in vim, so that it acts only along the current 'ignorecase' setting.
• Implements '\r' in the :s replacement string to insert a newline (multi-line matches were supported, but not multi-line replacement strings)
• <RETURN> now goes to the first non-blank character of the line below
• Ctrl-N/Ctrl-P work properly both in normal and insert mode
• '/<RETURN>' and '?<RETURN>' properly update the search direction for further n/N motions.
• Basic :map/:unmap support which works only with single-character to single-character mapping
• ViEmu scans its installation folder at startup for a '.viemurc' or '_viemurc' file, and executes it if present (only :set/:map/:unmap actually do anything there)
• New ex commands :prb[uild] and :qa[all]
• Ctrl-Y to yank the command line
• Behavior of the END key slightly altered to fix an interaction problem with Workspace Whiz

• Fixed input of Cyrillic text (and possibly others)
• Fixed T and F motions range when used as operator argument
• Fixed '' and `` so that they never jump between buffers, as vim
• Added experimental VS.NET 2002 support
• Implemented message 'N substitution on N lines' for :s
• Added a DLL to the package which prevented ViEmu from loading in some circumstances
• Fixed a problem when performing a :'<,'>s with the region going to the line before last
• Fixed a bug resulting in 'smartcase' and 'remove-read-only-warning' preferences not being honored at startup
• Prevented Intellisense from kicking in when using BACKSPACE in either VISUAL or NORMAL modes (it was causing trouble with VB)
• Made ViEmu check $HOMEDRIVE/$HOMEPATH and $HOME for the .viemurc or _viemurc file before checking the installation folder
• Implemented :cn/:cp, although they only work properly if the output window is 'pinned' (that is, it doesn't slide out of view automatically).
• Fixed cursor position after ^N/^P autocompletion

• :ta[g]
• ^W<Up>/<Down> to switch windows
• HOME now jumps to the hard beginning-of-line
• Ctrl-Shift-Alt-V globally toggles ViEmu on/off
• g*/g# search for the identifier under the cursor, down and up, w/o requiring a full-word match
• Implemented Ctrl-^ to switch to the previous buffer
• :set [no]incsearch/[no]is support
• CodeRush compatibility plugin implemented
• ^Wc and :clo[se] to close the current window/file
• Y in visual mode now returns to normal mode
• "INSERT --" is now "-- INSERT --" as in vim
• Cursor now updated after :d
• Block cursor not lost with some operations
• Undo/redo now should properly restore the cursor pos in all operations
• :f[ile] command
• New Welcome/Trial dialogs, and more links in Tools|Options|ViEmu

• Resharper compatibility: included code to enter insert mode automatically when an inline 'Rename' command is launched
• Visual Assist compatibility: included code to detect Visual Assist and guarantee proper order of editor window subclassing
• Visual Assist compatibility: included code to return from insert mode when pressing ESC even if Visual Assist has a drop-down opened
• Visual Assist compatibility: added :set [no]vax[esc] option to govern the behavior in the previous point

ViEmu 1.3 (November 5th, 2005):

• gv command: gets back into visual mode with the last visually selected range and range type
• '< and '> marks store the beginning and end of the last visual selection
• Command line editing with history for '/', '?' and ':' commands
• ex emulation: :set, :d[elete], :y[ank], :j[oin], :pu[t], :co[py]/:t, :m[ove], :p[rint], :nu[mber]/:#, :s[ubstitute, :&, :g[lobal] and :v[global]
• Regular expressions in search motions ('/' and '?') and ex commands
• & command in normal mode
• The following :set params work: [no]magic, [no]ignorecase, [no]smartcase

ViEmu 1.2 (September 29th, 2005):

• Folding support:
  • Cursor skips over collapsed folds when using 'j' and 'k' (the rest of the motions open the fold)
  • zf{motion} creates a fold for the enclosed text (works also directly in visual mode)
  • zd removes the current fold (not the text, but just the fold markers)
  • zR expands all folds
  • zM collapses all folds
  • zc, zo, za and zA toggle the current fold from open to closed, or viceversa
• Windowing support:
  • ^Ws splits the current window if it's not already split
  • ^W^W, ^Ww, ^Wj and ^Wk toggle between the two panes of the current file
  • If you issue :q and the current view is a split, the split is removed instead of closing the file
• Other:
  • Special mark `` (or '') to jump to the last jumped-from position (allows toggling back and forth)
  • '@@' to re-play last played macro
  • Now the result of incremental search (with '/') is shown with selection (except in visual mode)
  • :s[ubstitute] brings up the VS Replace dialog (poor man's :s)
  • :bui[ld], :comp[ile] and :deb[ug] commands

• Fixed problem in position history which would sometimes require pressing Ctrl-O twice to go back
• Fixed cursor positioning issue when repeating an 'o' or 'O' command
• Counts applied to 'o' and 'O' now work properly
• Much improved multiple-line input repeating with counts, '.', block-visual multi-input and within macros (also TAB)
• Count given to 'R' command is now honored (it was ignored)
• Any two-key motion started with 'g' could not be used as an operator (eg, 'dge'). Fixed.
• Made position-history aware of external file change events (such as Ctrl-Tab or clicking on the solution explorer or error window)
• Fixed 'r' inserting spurious naked LF's when given RETURN as argument, now it correctly inserts the appropriate terminator
• Both soft and hard TABs properly implemented in replace mode (for better integration with other tools and Intellisense, done along VS's conventions, not vims)
• Repeating input wich involved overstrike mode changes during input now works properly
• Now BACKSPACE and SPACE wrap around end of line, as in vim
• Fixed position history problems with unnamed files (both "Find results" window and just-created unnamed files)
• Made ESC in normal mode beep, as in vi/vim
• "Desired cursor column" is now updated after repeating input, as in vi/vim

ViEmu 1.1 (August 18th, 2005):

• "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

• 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
• Added the Ctrl-] command to jump to a symbol's definition
• 'o' and 'O' now perform correct automatic indentation
• Added an option to enable/disable ViEmu
• Ctrl-T/Ctrl-D in insert mode to indent / unindent the current line

ViEmu 1.0 (July 26th, 2005)