Sven Guckes@vim.org ©1995-2001

Last update: Wed Apr 11 11:11:11 MEST 2001

Why use a Vi clone? Why VIM?

"So - why should I use Vim and not standard Vi?"

First off, there is no "standard vi", ie no existing "vi" is exactly what the POSIX standard defines. Most implementations are "just about vi" with some or many differences. So I will simply denote such versions with "Vi" (capital 'v', small 'i').

Most of the popular "vi clones" do more than just fix bugs of Vi - they add new features which make work much easier. Almost all vi clones are better than Vi and I suggest that you switch to one of them.

The most popular/widespread vi clones are: elvis, nvi, vile, and vim. But check out calvin, elwin, lemmy, and viper, too.

But why switch to Vim? Well, Vim is a "vi compliant" implementation with many features you will find in other editors. Many features have also been improved, hence the name: "Vim - Vi IMproved". Vim runs on almost all kinds of operating systems, too.

The following is a summary of the most compelling features (with some examples), but the list is by no means complete. Vim-6 comes with 2.5MB of documentation (plain ASCII text) which explains all commands and options in detail, takes a look at the use on special systems, and gives a lot of examples for text editing in general.

Please note that this text is available as a webpage, so expect some changes to it. I will mark all changed text with a date in format "[yymmdd]" such as "[990101]" for "1999 January 1st". You are welcome to add and especially to correct me on this text!

Sven Guckes guckes@vim.org [a happy Vim user since 1994]


Vim - Technical Details

Availability
Vim does not run only on Unix and its many variants (most notably BeOS, FreeBSD and Linux, HPUX, IRIX, and Solaris), but also on many other operating systems, such as DOS and Windows (ie Windows-3.1, Windows95, Windows98, Windows2000, WindowsNT), AmigaOS, AtariMiNT, MacOS, OS/2, RiscOS, VMS.
vile: not available for AmigaOS, AtariMiNT, BeOS, MacOS.

Compatibility
Vim tries to be compatible whereever possible. It even simulates "known bugs". Fortunately, it allows the user to override this with ":set nocompatible". So you do not lose anything (well, except for a few bugs :-).

Language Support - Right-to-Left
Some languages have their text flow from right-to-left (eg Arabic and Hebrew). Vim supports this display mode, too. You can even mix left-to-right and right-to-left text. (Forget about Vi here!)
Support for Hangul (Korean), Chinese and Japanese will follow.
vile: no support for right-to-left display


Vim - support for terminals

adjust to resize of terminal [990824]
When you change the size of the terminal then Vi does not notice. With Vi you will have to exit, change the info on the terminal by adjusting COLUMNS and LINES, and restart.
If the terminal gives a signal then Vim notices a change and will adapt itself to the new size.

support for termcap and terminfo [990824]
On Unix systems info on terminals is either given by "termcap" or "terminfo". Vim knows about both kinds. Vim even knows about special key codes such as arrow keys - and even in different styles.

"builtin terminals" [990824]
Vim can be compiled with info on some standard terminal kinds. So you can use make use of terminals even if the terminal info is missing or is incorrect.

black&white or color? 40 or 80 lines? [990824]
On DOS Vim allows to chose the "screen mode".


Vim - Editing Features

Apart from the technical things, users mostly want features with "editing". Here are some of them:

Increased Limits [980101]
Many features are associated with editing. However, before you start making changes the editor must allow them. Vi does not allow you to edit every file - actually some (old) versions will accept only lines up to 255 characters. But a limit, however big, is a limit. Even 1024 characters usually won't do when you want to edit a "flow-text" where every paragraph is just one line. Some files are just too big for Vi and some implementations simply choke on the character ^D.
Vim allows you to edit *all* files, and yet recognizes when you do not have the permission to edit a file, showing "[RO]" for "read-only" files.

Multiple Undo
Probably the best new feature of Vim is the "multiple undo", which means that you can undo not only the last change (as with Vi) but the last N changes. (The number N is configurable and is only limited by available memory.)
I may add that the "multiple undo" alone is so helpful that I wouldn't want to go back to Vi. This feature certainly is nice for every beginner. should have it - even if only to make it easier for beginners as it allows to "back up" from commands that you "mistyped".

Redo
Gone back to far with "undo"? Well, "redo" the changes (with command ^R).
I often "undo" my changes to email when I want to recall some deleted text; I copy the text to some buffer and then back up with "redo" to continue writing. [980106]

Termcap Support - Terminal Adaptation and Arrow Key Support [980101]
Many Vi users get frustrated with having arrow keys on their keyboards and not being able to use them to steer the cursor with them. Although arrow keys are fine with Vi if the setup of the terminal and Vi match, you always get into trouble when you switch the current terminal as Vi does not adapt to other terminals - you usually have to quit, update, and restart.
Vim automatically a change of the current terminal and adapts to it (by reading the termcap entry). This also allows to recognize the codes of arrow keys. Vim also allows to move the cursor not only in command mode, but in all other modes, ie within insert mode, on the command line, when selecting text visually and even in replace mode.

Extended Text Objects [980106]
words, sentences, and paragraphs
Vi has commands for jumping to the begin or end of the current paragraph or sentence which can be combined with "change commands" to copy and delete these - but you cannot select any of these "text objects" from within. ie you need to jump to one end and then use a copy/delete with a jump to the other end.
Vim allows operations (like copy and delete) on the "current text object" from within, ie you do not need a jump to one or the other end at all. Vim also extends the notion of "current text object" by "current WORD", ie non-whitespace text, and also for "current word", ie normal words made of "letters" which are even configurable. (Again, this is not possible with Vi.) Furthermore, Vim allows to select text objects with or without surrounding whitespace (called "inner" and "all").
Examples:
        command description
        viw     visualize inner word
        viW     visualize inner WORD   (also works for "up-to-date")
        yas     yank (copy) all   sentence  (with    surrounding whitespace)
        dip     delete      inner paragraph (without surrounding whitespace)

Number Prefix of commands [980114]
Many commands can take a "number prefix" to perform the commands many times. However, this does not work some commands. For example, you can copy four lines with "4yy" - but you cannot put the copied text twice with "2p".
Vim fixes this - number prefixes can be applied to almost all commands.

Search Offsets [980114]
Whenever you search for patterns with Vi it will place the cursor on the first character of the matching text - but you must then look for the end of a match yourself.
Vim allows to specify a "seach offset", ie you can place the cursor relatively by "begin" or "end" of the matches text:
	pattern		cursor position	~
	/test/+1	one line below "test", in column 1
	/test/e		on the last t of "test"
	/test/s+2	on the 's' of "test"
	/test/b-3	three characters before "test"

Visual Selection [980106,990104]
Almost all commands in Vi operate/work on some text - but you cannot "see" this text prior to some command.
Vim lets you select text and shows it in "reverse" (aka "highlighting"). This allows you to visually check that you have selected the right text for the next command (usually one of "delete" or "yank", but also "filter"). You can "visualize" text from any position to another, ie starting anywhere within a line and then move to any other position; you can also select "linewise" by whole lines to easily highlight a "range" of lines. And you can select "blockwise", ie a rectangle on the screen.
With Vim you can directly operate on the current "visual text" with an ex command or filter (by typing ':' or '!' respectively).
Example: The following command selects the current inner paragraph (with "vip"), switches to ex mode with ':' (note that Vim automatically inserts the line range "'<,'>" to denote the line range of the visual text), and adds a "substitution command" to insert a '#' at the begin of each line, thus commenting them out with eg shell scripts: map ## vip:s/^/#/ This command does not get executed automatically as it is missing the 'return' at the end - on purpose! This still allows you to cancel the command by pressing 'escape'. Note that the "command line history" (see below) remembers the command even if you cancel it; this allows recalling and editing of it later.

Text Formatting [980107]
Many people are given Vi as the standard editor, but they just want to "write a simple email or post" with it. To make the text "look good" they usually want the editor to "reformat" the text to some textwidth. But such a command is not given within Vi; you are usually referred to "external commands" such as "fmt" and "par" (quite good, actually). But who wants to learn even more programs and install them everywhere?
Vim has built-in text formatting. So there is no need for external programs. Vim reformats text to a given "textwidth", unlike Vi which does this only for a given margin to the end of the terminal. And even if you just use the right-margin, Vim recognizes a change of currently used terminal and will update the textwidth accordingly (which Vi cannot do). Vim even preserves "cited/quoted text" by preserving the "quote prefix". And when you break a quoted line, Vim will add the quote prefix to the next line with the broken off text. Vim even adds two spaces after an end-of-sentence if you want that.
Vim allows to specify "comment characters" which allows to recognize whether the start of lines make it a "commented line". When you "break a line" (insert a newline) Vim then is able to add the "comment prefix" to the new line automatically. Vim's text formatting also makes use of this by recognizing lines with the same comment prefix and will reformat text for adjacent lines of the same comment prefix, preserving the comment prefix, of course. This allows to regard "quoted text" as "commented text" and reformat a "cascade" of quoted text (such as in Usenet posts) wil very few keystrokes (usually "gqip" suffices).

Completion for words, commands, and filenames [980101]
With Vi you must type each word - however long it might be.
Vim has commands to complete partial words, commands, and filenames. Word completion is usually used within the edit buffer to complete a word prefix of some long word or those of hard-to-type names in source code. Vim also looks at "dictonaries" (files with other words) for possible completions and lets you cycle forward/backwards through them.
Vim is smart enough to check files which are referenced with the current buffer. On the command line, the first word is assumed to be a command and can be expanded to its full name. Vim also expands filenames if the current command name suggests that the current word could be a filename. Vim also inserts the value of an option/variable. Example: Type the command ":set option=" and then type the "wildchar" ('^E' by default, but usually set to '^I' (TAB).

To TAB or not to TAB / TAB expansion [990301]
Program code usually uses TABs to indent statements of the same "level". But what is the best way to expand those TABs on the screen? How far should they be expanded on screen? (Multiple of 2,4, or 8 spaces?) Or should the cursor jump to the next "tab stop"? Maybe the should be expanded as spaces right away? Or should you use the least amount of TABs and spaces to reach the current indentation within the code? Well, chose the way you like: Apart from Vi's options "shiftwidth" and "tabstop", Vim offers the options "expandtab", "smarttab", and "softtabstop" to chose whatever you like best. And should you have the need to expand the TABs within an existing text then you chose your options and the command ":retab" to do that.

Digraph Input
Several languages include characters which are not included in ASCII and which thus are available by characters codes within 128-255. These codes are produced by special keyboards - but when you do not have such a keyboard available then you must either use a workaround or it is simply not possible at all. Therefore Vim supports the input of such characters with a command that takes the next two characters as a combination - hence the word "digraph" ("two letters"). Example: Enter the keys ^K + $ + $ to get a pound sign: '£'.
The German language has three umlauts which can be entered easily with the combination of a vowel and inverted commas ('"'). Example: Enter the keys ^K + a + " to get an 'ä'.
And those who speak Nordic languages will use the letters "Åæø" and the Spanish will want 'ñ' ('n'+'~').
By the way, the current version of Vim has some rudimentary support for "Unicode" which allows to type text in eg Chinese and Japanese.

Filetype Recognition [..,990301]
If you are using a combination of Unix, DOS/Windows and Macintosh (chose any two) then you certainly know that the end-of-line is given by different character combinations. This forces you to constantly change the "filetype" accordingly.
Editing files of all filetypes is no problem for Vim - it recognizes the filetype automatically and lets you start editing right away. Files can be kept with their current filetype or written out any other filetype.
Example: You "edit file" and Vim shows "[dos]" to tell you that the file is a DOS file. You then ":set fileformat=unix" and ":write" the file again. (These commands can be abbreviated to ":se ff=unix" and ":w"). Result: The file's line-ends is converted to Unix style.

Command Line History and Command Line Editing
Have you ever mistyped a long command in Vi an just hated to retype it? Isn't it sad that shells have a "command history" and Vi does not? Well, Vim has both - command line history and editing. Just use the arrow keys on the command line to recall the last command, move the cursor back and forth, and delete and insert characters as you like.

Search Pattern History
The search pattern history is just like the command line history - but it is a special history for search patterns only. The "pattern history" has been separated from the "command line history" to allow easier access.
No, Vi does not have this.

Configurable Words [980101]
Vi checks for an abbreviation after you "complete" a word, ie by typing a non-word character. Whatever the difference between a "word character" and a "non-word character" - Vi doesn't tell you about it, not lets you change the definition.
Vim's online help tells you about the definition of "words" and also tells you that you can change the definition to your taste, or rather, to whatever kind of language you currently want to use. This helps you both with writing txts in other languages and writing code in some other programming language.
The timout solution and associated problems: Another natural way of editing is to abbreviate editing tasks by defining a short sequence of keys as an abbreviation of a sequence of commands. These are known with Vi as "mappings". These abbreviations however can also occur as a part of some text - therefore Vi needs *some* way to distinguish it from text. The solution to this problem is to *wait* a little time (know as the "timeout") before the check this made whether the recent input is a command or whether the user continues typing text. Although this is a good method, the timeout of Vi is hardcoded and thus cannot be changed. But when you have a slow connection then the characters of your input might arrive with a delay exceeding the timeout, thus making it impossible for it to recognize an abbreviated command sequence. With Vi your simply lost here - but Vim allows you to adjust the timeout. This is also nice if you are a fast typer ("touch typist") as you can also lower the timout delay.
Modes vs mapping: Vim distinguishes between more modes than Vi - allowing you to define abbreviations and map keys for each of those modes separately. This difference is a benefit as you can define an abbreviation only for the command line, such as an often used filename. Example:
	cab TODO ~/projects/todolist.txt
	cmap ##  e TODO
Now switch to command mode with ':', type "##" and you will see the command "e TODO"; now type a space to eind the word "TODO" and have it expanded to "~/projects/todolist.txt"; then type a return to have Vim accept this edit command.

Multiple Buffers
Vi can only deal with two buffers - the current buffer and "the other buffer". This poses many problems with editing more than just one file: You cannot quickly switch to another file for editing, and switch back for editing the file before. Also, Vi's safety feature that forces you to save changes before switching, gets in the way here: You must "save" ("write") the changes of the edit buffer back to file before you switch - otherwise the changes are lost. Also, switching to another file makes Vi "forget" the set "marks" and the contents of the unnamed buffers. (Some versions seem to lose the contents of the numbered buffers, too.)
Vim allows to edit many files at the same time without having to write back changes before switching. Vim keeps a "buffer list" of all edited files and lets you switch forward and backward or directly to any buffer number. You can also switch by part of the path/filename and even cycle through possible matches before switching. And Vim does not lose the contents of numbered buffers when you switch and also keeps the set marks. The maximum number of buffers is only limited by available memory.

Screen Splitting into Windows [980106,990101]
Vim has many commands to "split the screen" into (horizontal) windows. The height of each window can be decreases and increased, and you can jump around between them as well as cycle them. This makes it very easy to ":split" the current window in two separate windows, each showing a different part of the same file or different files. Vim even has a command to change to the filename under the cursor ("gf").
You cannot split windows vertically - yet. This feature was much asked for with Vim6, though, so it is likely that you will see this feature soon.
Need I say that Vi does not have such commands?

Syntax Coloring
This feature probably is the best one of all: Coloring Text. The colors can not only be given to special words or characters, but they are defined by "rules" that can define a "language" - hence the name "syntax coloring".
The syntax coloring is general enough to allow rules for any kind of language, usually programming languages. The best effect is that you can easily see whether some "beginning" matches some "ending" to avoid errors in structure. It is equally nice to see variable names and constants in their own color.
Mind you, this does not make Vim a "syntax checker" as this can require to (always) check the whole text (source code). But the rules can be made as complex as need be.
vile: Does syntax coloring with external filters and buffer hooks.

Autocommands
"Autocommands" allow to execute commands automatically with editing files. These autocommands can be executed when you start or end editing files in combination with filename patterns. A typical use of this is to "change the textwidth to 70 when editing a C source file":
	au BufRead *.c tw=70
This can get more complex, of course, such as automatically uncompressing compressed files just before loading them into an edit buffer. Someone used this to remap keys such that you can use them to select files within an edit buffer as if you were using a file browser.
By the way, Vim uses autocommands to load the appropriate color setup for the current file, eg loading the rules from tex.vim for TeX and LaTex files.

Macro (Map) Recording
Vi users who write "mappings" to abbreviate a series of commands know how tedious it can be to remember the keystrokes for this. Vim makes it easy with "macro recording": The letter 'q' (which is unused in Vi, btw) is used to start the recording; the next letter is the name of a register which is to store the keystrokes. Whatever you type after that is stored within the register until you type another 'q'. That's it. You can then play back this sequence with the command '@' followed by the register letter/name.
Example: qa Start recording into register 'a' G jump to last line of current buffer ?^-- $^M search backward for a line with sigdashes d/^$^M delete unto next empty line q end recording This simply deletes the signature from the current file. You can now edit another file with a signature and have it removed by simply replaying the macro with "@a".

Viminfo - Saving your editing for the next session [990301]
Vim saves all those extra stuff that you typed during an edit session into an extra file - the viminfo file. This contains the list of filenames you had edited together with the "marks" that you have set for each; also saved are the registers (read: scrap buffers to hold some text) with their contents, so you can "paste" from them at your next session. [This has saved the lives of many editors, I hear.] Furthermore, Vim can save the histories (command line, search patterns), as well as global variables defined during the editing. Further options allow to chose a filename for the viminfo file, the maximum number of filenames to remember, and a maximum number to the lines saved within each register. But that's for experts. ;-)

Online Help - ":help"
Vim gives you the command ":help" which will open a new window with the "helpfile" ("help.txt"). From there you can jump to other topics by placing the cursor on a "tag" (eg "|quickref|") and jump to the associated helptext with the command ^] (control-]). Using ":help option" you can directly see a definition of "option". You can even use this system for your own help text and source code. Vim ships with the utility "ctags" which "creates tagfiles" to speed up finding the relevant text in other files.
Vim has a syntax file for its own helpfiles, too, so you can easily see tags in their own color.

GUI - Of Menus and Mice
Vim-5 now sports a graphical user interface (GUI). Vim with code for GUI can be started as "vim -g" or as "gvim" and then gives you features that many GUI programs have. This has several advantages: You can click on icons to issue commands (or command sequences) which makes it easier for beginners as they do not need to know them. (Just click on the icon with the floppy - ":write".) You can also use the mouse for copy&paste, ie select some text, copy it, click onto another position and have the text inserted there. Vim also has a "scrollbar" that shows how the window's content relates to the whole of the "file" (edit buffer). You can define "menus" to present commands that you need most often with your editing, but cannot be bothered to remember. Some GUIs also allow "tear-off menus", ie you can tear them off the menu bar and stick them onto your desktop to keep them available; no need to open them menu then - just click on an item. The GUI allows font selection, ie text can be displayed in different fonts, allowing use of bold, italics, and outline within the font. (But mostly you want to use a monospaced font for all the text, anyway.) Some GUIs allow to define colors for buttons and the cursor. Gvim also has a buffer selection dialog, so you can choose a buffer with a mouseclick. And some people just do not have enough experience with terminals to get some things working on them, eg arrow and function keys, text attributes, and color. Last but not least, you can use more than the eight or sixteen colors usually available on terminals; you can have 16, 256, or even 65 thousands of colors. "Look at 'em colors!"


Vim - Extra Support

Support for GUI
Vim can be linked several GUI sets: Athena, Motif, Lesstif.

Support for OLE (and thus for Microsoft Developer Studio) [990108]
Vim can be integrated with Microsoft Developer Studio using VisVim. An extra archive is available for this. See also: Page on VisVim

Support for Perl

Support for Python

Support for UTF-8


DONE/TODO

reasons to use a vi clone: development and support
(mailing lists, newsgroups, webpages)
documentation:
        elvis           Steve Kirkendall
        nvi             Keith Bostic
        vim             Bram Moolenaar
        vi archive      R. Olsen

URL:         http://www.math.fu-berlin.de/~guckes/vim/why.html
URL:         http://www.vim.org/why.html (mirror)
Created:     Thu Jan 01 00:00:00 CET 1998
Send feedback on this page to
Sven Guckes guckes@vim.org