URL(for now): https://www.vim8.org/faqnew/
URL (after reqrite): https://www.vim8.org/faq/
Created: Fri Feb 20 00:00:00 CEST 1997
Last update: Mon Jun 05 12:00:00 MET DST 2000
Maintainer: Sven Guckes [email protected]
FAQ short description:
This text contains answers to FAQs (Frequently Asked Questions)
about the editor "VIM" (Vi IMproved),
a vi clone for many operating systems.
What is Vim? What platform does it run on?
How compatible are Vi and Vim? What are the improvements of Vim over Vi? What are the new features of Vim-5?
Where can I get Vim? What is the latest version of Vim? Where can I find the latest version of Vim?
How do I use this editor?
Who wrote Vim?
Is there a mailing list available? Is there an archive available for the Vim mailing list?
Where can I send my questions about Vim?
Is Vim free? Can I copy Vim? Can I bundle Vim with my work?
This article is provided as is without any express or implied warranties. While every effort has been taken to ensure the accuracy of the information contained in this article, the author / maintainer / contributors (take your pick) assume(s) no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
This article is © Copyright 1996-1997 Laurent Duperval. You may distribute it as you wish provided this copyright and the above disclaimer is also provided. You may not sell it without express consent from the author. You may not distribute a modified version of this article without express consent from the author.
(We need to talk, Laurent!)
All credits are given on the VIM Users Page:
https://www.vim8.org/user.html
Bram Moolenar <[email protected]
>
Sven Guckes <[email protected]
>
Robert Webb <[email protected]
>
George V. Reilly <[email protected]
>
Tony Nugent <[email protected]
>
Ingolf Markhof
<[email protected]
>
Stan Brown <[email protected]
>
Raul Segura Acevedo <[email protected]
>
Benjamin Elijah Griffin <[email protected]
>
Well, an editor is simply for entering text. You should understand text as in "the set of characters representing the values from zero to 255." And please remember that "characters" are always an interpretation of those numbers, ie the dots that appear on your screen depend on the current "font".
Any typesetting or laying out of the document usually is secondary. With an editor, one's main concern is entering text, not making the text look good. Examples of editors other than Vim and Vi are Emacs, Crisp, Brief, and xedit.
A word processor is used mainly to do layout of text. This means positioning it, changing the way it appears on output. More often than not, the final document is meant to be printed or typeset or what have you, in order to present it in a pleasing manner to others. Examples of word processors are Microsoft Word, WordPerfect, FrameMaker, and AmiPro.
Most of Vim was written by Bram Moolenar, with contributions from too many people to mention here. Try ``:h credits'' for a complete list.
Vim is based on Stevie, worked on by Tim Thompson, Tony Andrews and G.R. (Fred) Walter.
Very. A special mode (``:set compatible'') makes Vim behave almost exactly like Vi.
Here is a short summary. For more information, do ``:h diff''.
Here is a list of some of the improvements of Vim 4 over Vim 3. For a complete list, do ``:h vim_40''.
Vim 5.0 is not officially out yet, but it will have syntax highlighting! And a command language!
Vim is Charityware. There are no restrictions on using or copying Vim, but the author encourages you to make a donation to charity. A document explaining how to do so is included in the distribution. You are allowed to include Vim on a CD-ROM but you should send the author a copy. Please try ``:h copying''.
A mailing list is available for Vim. See the next question . Vim does not have a newsgroup of its own. But the appropriate newsgroup to post to is comp.editors . There is also a Vim home page available at <URL:http://www.math.fu-berlin.de/~guckes/vim/ >. More information can be found in
There are three mailing lists for Vim (description to follow). You can join any of the lists by sending an empty mail message to the appropriate list handler. If for any reason, things don't work, contact [email protected].
mail vim-(un)[email protected]
mail vim-announce-(un)[email protected]
mail vim-dev-(un)[email protected]
Each mailing list serves a different purpose and you should not crosspost between them. This is a brief description of each list:
If you have a question about the usage of Vim then please post it to comp.editors or to the vim mailing list . Please note that if you send a message to a Vim mailing list but are not subscribed, your message will be discarded. You must subscribe in order to send mail to the mailing lists. Do not send mail to the mailing lists for subscription or unsubscription. (The maintainer of the list hates that! So do the people subscribed to the lists.)
There is an archive available for the announcements made on the vimannounce mailing list at http://www.egroups.com/list/vimannounce/
There is also a mail archive available by FTP if you need to check out old messages sent to one of the other lists. They are available at:
<URL:ftp://ftp.ii.uib.no/pub/vim/mail-archive/vim/maillist.html
>
<URL:ftp://ftp.ii.uib.no/pub/vim/mail-archive/vimdev/maillist.html
>
<URL:ftp://ftp.ii.uib.no/pub/vim/mail-archive/vimannounce/maillist.html
>
Well, you don't need to because there are none. ;-) But on the off chance that you may find an unexpected feature, you may send a description of it to the Vim Development list. Take a look at <URL:http://www.math.fu-berlin.de/~guckes/vim/development.html#bugreport > to see what type of information should be sent when making a bug report. We are looking for someone to take over the tasks of our previous bug maintainer. If you are interested, send a message to Bram <[email protected] >. If you have patches that you would like to submit for approval and incorporation in future versions of Vim, you can send them to Bram <[email protected] >.
This FAQ will be posted on a (hopefully) regular basis to the comp.editors newsgroup. The latest version can be found on https://www.vim8.org/faq/ Eventually, it should make its way into news.answers and rtfm.mit.edu . You can also find a searchable version of this and many more FAQs at the Hypertext FAQ Archive at <URL:http://www.landfield.com/faqs/ >.
This FAQ covers mainly Vim-specific questions. You may find more information suitable for most Vi clones by reading the Vi FAQ. It is posted regularly on comp.editors . You can also find a copy at <URL:ftp://rtfm.mit.edu/pub/usenet-by-group/comp.editors >. Please note that although I maintain the FAQ, I am not the best resource to answer questions about Vim. If you send a question about using Vim diretly to me, 9 times out of 10 I will redirect you to the Vim mailing list or to comp.editors . So you might as well send your questions directly there since you're liable to get a more accurate and useful response than I could give you.
The latest version is 4.6. The latest alpha release is 5.0l (as of August 6 1997). You should not use the alpha version unless you can read and modify C code rather well. Otherwise, I suggest you wait for the beta release.
The main archive for the latest versions of Vim is <URL:ftp://ftp.oce.nl/pub/misc/vim >. The directory structure:
/pub/misc/vim/amiga /pub/misc/vim/atari /pub/misc/vim/beta-test /pub/misc/vim/os2 /pub/misc/vim/pc /pub/misc/vim/unix
The latest public release can be found in the atari, amiga, os2, pc, and unix directories. The latest beta-test versions can be found in the beta-test subdirectories.
You can probably also find the latest version at:
<URL:ftp://jagubox.gsfc.nasa.gov/pub/unix/vim/
>
(USA, fast)
<URL:ftp://ftp.nuxi.com/pub/vim
> (USA, fast)
<URL:ftp://nuxi.ucdavis.edu/pub/vim
> (USA, fast)
<URL:ftp://petrified.cic.net/mirrors/vim/
> (USA)
<URL:ftp://ftp.fu-berlin.de/pub/misc/editors/vim/
>
(Germany)
<URL:ftp://ftp.is.co.za/applications/editors/vim/
>
(South Africa)
<URL:ftp://ftp.progsoc.uts.edu.au/pub/vim/
>
(Australia)
<URL:ftp://ftp.uni-erlangen.de/pub/utilities/vim/
>
(Germany, incomplete)
Vim should compile with no problems on most flavors of Unix and on DOS, OS/2, Ataris, Amigas, Windows 95, and NT. Binaries for other systems are also available.
Unless you are on a Unix station, you may not need to compile Vim since there are various binaries available for Windows, Windows 95, Windows NT, DOS, OS/2 and Amiga. But if you need to compile it, you must have a C compiler and a make utility. Most commercial C compilers come bundled with a make utility, so if you've got one of those, you're in luck. If you need a compiler or if your make utility doesn't like the Makefiles provided with Vim, you can get the GNU C compiler and GNU make at <URL:ftp://prep.ai.mit/edu/pub/gnu > and its mirrors. At that same site, you can also find sed, binutils, and other GNU tools (such as gzip) which can be useful on certain systems. For DOS systems, you can look in <URL:ftp://ftp.coast.net/SimTel/msdos/ >. If you plan on compiling the GUI version of Vim under Unix, you must have some kind of widget library. One of these three should suffice:
Note: This section contains various macros written in Vim's macro language, called ``<> notation'' (you can find the description by doing ``:h key_notation''). All macros should be entered as is in your .vimrc file or on Vim's command line. You should even be able to cut and paste the information. This is a short description of the language:
<Esc> Escape key <C-G> CTRL-G <Up> cursor up key <C-LeftMouse> Control- left mouse click <S-F11> Shifted function key 11 <M-a> Meta- a ('a' with bit 8 set) <M-A> Meta- A ('A' with bit 8 set) <t_kd> "kd" termcap entry (cursor down key)
If you want to use this notation in Vim, you have to remove the 'B' flag from 'cpoptions' and make sure the '<' flag is excluded. The default values for cpoptions should work fine.
:set cpo=ceFs
For mapping, abbreviation and menu commands you can then copy-paste the examples and use them directly. Or type them literally, including the '<' and '>' characters. This does NOT work for other commands, like ``:set'' and ``:autocmd''!
Other tips, not appearing in this FAQ, can be found by doing ``:h tips''.
Help can be found for all functions of Vim. In order to use it, use ``:h''. This will bring you to the main help page. On that first page, you will find explanations on how to move around. Basically, you move around in the help pages the same way you would in a read-only document. You can jump to specific subjects by using tags. This can be done in two ways:
Use ``<Ctrl-T>'' to jump back to previous positions in the help files. Use ``:q'' to close the help window.
If you want to jump to a specific subject on the help pages, use ``:h {subject}''. If you don't know what to look for, try ``:h index'' to get a list of all available subjects. Use the standard search keys to locate the information you want. By version 6 or 7, we should have a search engine available. ;-)
In order to keep Vim from writing a backup, you must also do ``:set nowritebackup''.
Well, you can use ``set noerrorbells" but it does not turn off the bell for all cases. It only makes a difference for error messages; the bell will be always be used for a lot of errors without a message (e.g., hitting <Esc> in Normal mode).
If you want Vim to stop beeping then all you need is ``:set vb'' which tries to do a screen flash rather than an audible beep. Some terminals can't do screen flashes, but if yours does and you don't want it to flash or beep then use ``:set vb t_vb=''.
:map <Tab> right-hand-side
On some keyboards the escape key is not placed very well. It's either part of the numeric block or it can be a small button (as with some Macintosh keyboards). But do not despair - make your own escape key! You can map one of the commands keys you do not need to Esc. Example: map CTRL-O to ESC:
:map <C-O> <Esc>
To tell Vim where to find the help file, ``:set helpfile'' to the correct value, i.e., including the full path. As with most options you can abbreviate ``helpfile'' to ``hf''. On the other hand, if your VIM environment variable points to the directory containing the help file, vim will find the help file with no need to ``:set hf=''.
Use ```a'' (that's a backtick!). If the backtick is awkwardly placed on your keyboard, the following maping may be useful to you:
map ' `
Use ``:r!command''.
The abbreviation consists of a non-id character followed by two id characters, which does not satisfy either category of a ``full-id''. However, ``_ps'' and ``'p'' will work.
The command 'o' will jump to the beginning/end of the highlighted text.
The thing is that the ``no'' is not actually part of the option's name; the name comes after that. So after ``no'', Vim knows to complete any boolean setting name (starts the completion just after the ``no'', which is not part of the name). After ``n'', Vim will complete all setting names starting with ``n''. It would be a bummer if you wanted to complete ``number'', but had to wade through all the boolean option names with ``no'' prepended too.
No. The digraphs table is defined at compile time. You can only add new ones. Adding a command to remove digraphs is on the todo list.
You can call a non-interactive spell checker from Vim without a problem. A function to look up a word is included with the command ``K''. So what you do is get such a spell checker, then you issue the command ``:set keywordprg=ispell'', and then hit ``K'' on the word you want to look up, i.e., check. If you need to give options to your spell checker command, escape all spaces with a backslash.
If you need to use an interactive spell checker and are working with Unix, you can try this approach proposed by Ives Aerts <[email protected] >:
noremap ;ispell :%! ispell-filter<CR><C-L>
where ispell-filter is the following script:
#!/bin/sh # # This little script can be used to run ispell on stdin, returning the result # through stdout. # It can be used from VI like this (or map it to a key sequence): # :%! ~/bin/ispell-filter # cat > /tmp/tmp.$$ ispell $* /tmp/tmp.$$ < /dev/tty > /dev/tty cat /tmp/tmp.$$ rm -f /tmp/tmp.$$
or this macro proposed by Dr. Charles E. Campbell Jr. <[email protected] >:
map #fi :w<CR>:!ispell %<CR>:e %<CR>
In Insert mode, you can copy the character above the cursor to the current cursor position by typing <Ctrl-Y>. The same can be done with the characters below the cursor by using <Ctrl-E>. This is neat when you need to duplicate partial lines without going through the process of yanking a line and deleting the unwanted part.
To remove all empty lines do ``:g/^$/d''. ":g/^\s\+$/d" deletes blank lines, ie lines that contains spaces and tabs only.
You can try ``:v/./.,/./-1join''. Note that this will give an error message if the empty lines are at the end of the file. To correct this, use the following mapping instead:
map _b GoZ<Esc>:g/^[ <Tab>]*$/,/[^ <Tab>]/-j<CR>Gdd
If you are using the GUI version of Vim, with the Motif or Athena interface, you can actually cut and paste between the two, and text will be copied exactly; that is, tabs will not change into spaces, and if you copy a rectangular block, then that is what you will paste too!
Otherwise, in a terminal Vim, use these mappings:
" _Y: Yank the highlighted block of text (or a single line) to a tmp file. " _P: Put the text yanked with \_Y (possibly in another invocation of Vim). " nmap _Y :.w! ~/.vi_tmp<CR> vmap _Y :w! ~/.vi_tmp<CR> nmap _P :r ~/.vi_tmp<CR>
Now you just highlight the area you want to copy with ``V'' etc, and yank it with ``_Y''. Then you can paste it in another Vim with ``_P''.
For those that are really short on disk space, you can compress the help files and still be able to view them with Vim. This example assumes you have gzip on your system. You do have it, don't you? :-) If not, you will need to adapt it to work with a different compression utility.
set helpfile=<dirname>/vim_help.txt.gz autocmd BufReadPost *.txt.gz set bin | '[,']!gunzip autocmd BufReadPost *.txt.gz set nobin set cmdheight=2
Where ``dirname'' is the directory where the help files are. If you already have included autocommands to edit ``.gz'' files you should omit the two ``autocmd'' lines.
Some options are compiled into Vim. If you want to enable these options, then you must modify the feature.h file. You can see what compile-time options are available by looking at the version number (:ver). It will give you something like this:
Compiled with (+) or without (-):
+autocmd +builtin_terms +cindent -compatible +digraphs -emacs_tags +fork()
-GUI +insert_expand -langmap +lispindent -rightleft +smartindent -terminfo
+viminfo +writebackup +X11
As the example shows, all options compiled into the Vim binary are preceded by a '+'. All options that are not compiled in are preceded by a '-'. All options that do not appear in this list do not need to be compiled in.
To format C code, use = instead of Q. Try ``:h C_indenting'' to get more information on controlling the way your code is formatted.
You need only end the input with <ESC> (not <Ctrl-V><Esc>).
This is normal behavior. If your window flashes, then you've got the visual bell on. Otherwise, you should hear a beep.
Vim (and most, if not all, other implementations of Vi) needs a timeout to tell the difference between a simple escape and, say, a cursor key sequence. When you press a key in normal mode (and even in insert mode) and that key is the beginning of a mapping, Vim waits a certain amount of time to see if the rest of the mapping sequence follows. If the mapping sequence is completed before a given timeout period, the mapping for that sequence of keys is applied. If you interrupt the mapping, the normal actions associated with the keys are executed.
For example, if you have a mapping defined as ``:imap vvv Vim is great!!'' and you type ``vvv'' quickly, the ``Vim is great!!'' will be inserted into your text. But if you type ``vv v'' then that is what will put into your text. This is also true if you type ``vvv'' too slowly where ``too slowly'' is longer than the value for the timeout option. Setting the timeout option to a larger value can help alleviate problems that appear when using function keys over a slow line. Do ``:h timeout'' for more information on using this option and its cohorts.
Add ``:set cpoptions=ces$'' to your .vimrc. Vi-compatible behavior can be controlled like this. Do ``:help cpoptions'' for more information.
Look at this problem this way: If there is a newline before the character then the character is the first character of the next line, i.e., it follows the start-of-line meta character (^). So the command to use is to look globally for all lines starting with the given character and the command to use on these lines is ``go back one line'' and ``join'' which will remove the next newline. The resulting command is:
:g/^|/-1join
:?^|?,/*$/join
In either case, ``:set paste'' will do the trick. Use ``:set nopaste'' to return to normal.
For map!ed key sequences, you have a these tricks also;
Normally, you shouldn't need these tricks. When ``:unmap'' finds an argument that is not a ``from'' part, it looks for a matching ``to'' part and unmaps that one.
There are a couple of things that could be going on: either you are using Vim over a slow connection or Vim doesn't understand the key sequence that your keyboard is generating.
If you are working over a slow connection (such as a 2400 bps modem), you can try to set timeout or ttimeout. These options, combined with timeoutlen and ttimeoutlen, may fix the problem. Do ``:h timeout'' and ``:h timeoutlen'' for a better description on how to use them.
The preceding procedure will not work correctly if your terminal sends key codes that Vim does not understand. In this situation, your best option is to map your key sequence to a matching cursor movement command and save these mappings in a file. You can then ``:source'' the file whenever you work from that terminal.
For example (make sure you adapt the example to your personal needs):
for k=1:10, stuff .. end; ^^^ This word marks the end of a loop and I'd like it to be automatically outdented to the same column as the word for.
The following macro will do this (from Raul Segura Acevedo <[email protected] >):
:iab end; <C-D>end;
This abbreviation takes effect when you type a non-keyword character after it (``;'', ``!'', space, tab, <Esc>, <CR>, etc). You can load this macro automatically using the following autocommands:
au! BufEnter *.f,*.ff iab end; <C-D>end; au! BufLeave *.f,*.ff iunab end;
As a matter of fact, there is. You can find the latest versions of contributed macros at <URL:http://www.grafnetix.com/~laurent/vim/macros.html >. At the time this version of the FAQ was updated, the following macros were available:
Instead of using :map lhs rhs, use :noremap lhs rhs. For abbreviations, use noreabbrev lhs rhs. The ``nore'' prefix prevents the mapping or abbreviation from being expanded again. You must be using version 4.5 or greater.
From Benjamin Elijah Griffin <[email protected] >:
Vim modelines are crippled to reduce the security hazards of modelines. For much closer to vi modeline behavior (with the major risks involved) you can use Benjamin Elijah Griffin's modeline autocmd system. You can find it at <URL:http://www.netusa.net/~eli/src/modeline.html >.
There are a few ways to do this. All of them involve the use of autocommands. Try ``:h autocommand'' for more information.
au!BufRead *.c,*.cc,*.h set fo=croq cin noic au!BufEnter *.c,*.cc,*.h ab #i #include au BufEnter *.c,*.cc,*.h ab #d #define au BufEnter *.c,*.cc,*.h map _hello_world :"Hello World"<CR> au BufEnter *.c,*.cc,*.h normal _hello_world au!BufLeave *.c,*.cc,*.h unab #i | unab #d au BufLeave *.c,*.cc,*.h unmap _hello_world
The ``!'' is used just in the first autocommand for each event (BufEnter, BufLeave, etc.).
autocmd BufNewFile *.tex read ~/.vim/texmodel autocmd BufEnter *.tex source ~/.vim/texrc autocmd BufLeave *.tex source ~/.vim/notexrc
Remember that all settings that you modify in a BufEnter or BufNewFile event may need to be unset with a corresponding BufLeave event. By using a first file pattern with a value of ``*'', you can define default settings for all your files. The ``mapclear'' and ``abclear'' commands can clear all your mappings or abbreviations if needed.
Darren Hiebert <[email protected] > says:
Ctrl-] is the the default telnet escape key. Most version of telnet allow changing or disabling the default escape key. See the man page. If possible, try to use ``rsh'' instead of ``telnet''. It will avoid this problem.
The support for Win32 console mode applications is very buggy in Win95. For some unknown reason, the screen updates very slowly when Vim is run at one of the standard resolutions (80x25, 80x43, or 80x50) and the 16-bit DOS version updates the screen much more quickly than the Win32 version. However, if the screen is set to some other resolution, such as by ``:set columns=100'' or ``:set lines=40'', screen updating becomes about as fast as it is with the 16-bit version.
Changing the screen resolution makes updates faster, but it brings problems with it of its own. External commands (e.g., ``:!dir'') can cause Vim to freeze when the screen is set to a non-standard resolution, particularly when columns is not equal to 80. It is not possible for Vim to reliably set the screen resolution back to the value it had upon startup before running external commands, so if you change the number of lines or columns, be very, very careful. In fact, Vim will not allow you to execute external commands when columns is not equal to 80, because it is so likely to freeze up afterwards. The maintainer of the Win32 port, George V. Reilly, says he's almost done with the GUI version of Vim. When it is completed, it should fix all these problems. In his own words:
My position at this point is that the console mode APIs are irredeemably broken on Windows 95 and that I'm no longer interested in trying to come up with workarounds and hacks when my limited time is better spent trying to get an alpha of the Windows GUI version out the door. I strongly urge you to use one of the three standard resolutions (80x25, 80x43, or 80x50) and wait for the GUI version. Or upgrade to NT, where the console mode stuff works. Sorry.
None of the above applies on Windows NT. Screen updates are fast, no matter how many lines or columns the window is set to, and external commands will not cause Vim to freeze.
Firstly, the Win32 version isn't that slow, especially when the screen is set to some non-standard number of lines or columns. Secondly, the 16-bit DOS version has some severe limitations: it can't edit big files and it doesn't know about long filenames. The Win32 version doesn't have these limitations and it's faster overall (the same is true for the 32-bit DJGPP DOS version of Vim). The Win32 version is smarter about handling the screen, the mouse, and the keyboard than the DJGPP version is.
There are no good reasons to run the 16-bit DOS version on NT. The Win32 version updates the screen just as fast as the 16-bit version when running on NT. All of the above disadvantages apply. Finally, 16-bit DOS applications can take a long time to start up and will run more slowly. On non-Intel NT platforms, the DOS version is almost unusably slow, because it runs on top of an 80x86 emulator.
In the properties dialog box for the MS-DOS window, go to ``MS-DOS Prompt/Misc/Fast pasting'' and make sure that it is not checked. You should also do ``:set paste'' in VIM to avoid unexpected effects. See ``:h paste''.
Also, in the Properties dialog's ``Misc'' tab, you want to make sure that ``Mouse Exclusive Mode'' is not checked. If you want to use the mouse in the Vim way, also make sure ``Mouse Quick Edit'' is not checked. (You can still cut and paste with the mouse by using the toolbar buttons.)
(A dead key is an accent key, such as acute, grave, or umlaut, that doesn't produce a character by itself, but when followed by another key, produces an accented character, such as a-acute (á), e-grave (è), u-umlaut (ü), n-tilde (ñ), and so on. Very useful for most European languages. English-language keyboard layouts don't use dead keys, as far as we know.)
You don't. The console mode input routines simply do not work correctly in Windows 95, and we have not been able to work around them. In the words of a senior developer at Microsoft:
Win95 console support has always been and will always be flaky.The flakiness is unavoidable because we are stuck between the world of MS-DOS keyboard TSRs like KEYB (which wants to cook the data; important for international) and the world of Win32.
So keys that don't "exist" in MS-DOS land (like dead keys) have a very tenuous existence in Win32 console land. Keys that act differently between MS-DOS land and Win32 console land (like capslock) will act flaky.
Don't even mention the problems with multiple language keyboard layouts...
You may be able to fashion some sort of workaround with the digraphs mechanism.
Alternatively, you can try one of the DOS versions, where deadkeys do work.
Dead keys work on NT. Just type them as you would in any other application.
Work has begun on a GUI version of Vim for Win32. Apart from the features you might expect in gvim, it is expected that this version will also be able to handle dead keys correctly and that the problems with external commands will be a thing of the past.
On Unix, Vim is prepared for links (symbolic or hard). A backup copy of the original file is made and then the original file is overwritten. This assures that all properties of the file remain the same. On non-Unix systems, the original file is renamed and a new file is written. Only the protection bits are set like the original file. However, this doesn't work properly when working on an NFS-mounted file system where links and other things exist. The only way to fix this in the current version is not making a backup file, by ``:set nobackup nowritebackup''.
From John Velman, <[email protected] >:
To copy something from the Vim window to the clipboard,
From Stan Brown <[email protected] >: In Windows 95, you can use a simpler procedure, which works even when you're using the mouse in the Vim way inside the Vim window (see question 6.4). To paste into Vim, put Vim in insert mode and click the Paste button on the Vim window's toolbar. (Depending on your setup, you may want to use ``:set paste'' before and ``:set nopaste'' after pasting.)
To copy from Vim to the clipboard, click the Mark button (the square) on the toolbar, highlight the desired text with the mouse, and click the Copy button.
It's actually caused by Windows 95. When CapsLock is down, it acts just as if Shift were being held down: everything gets shifted, not just the alphabetical keys.
If ``:set lines=##'' doesn't work for you, then you should use the ``:mode'' command. Look up ``:h :mode'' for more info.
When using Vim in an xterm it renames the title of that window to ``Thanks for flying Vim'' on exit. Use ``:set notitle'' to stop this behavior.
Map <Ctrl-Z> to prevent the suspending. Here are some suggestions:
map <C-Z> <C-V><C-V>
:map <C-Z> :shell<CR>
:map <C-Z> :"suspending disabled<CR>
For the last example, the double quote is necessary in order to keep the message on the status line.
The GUI support in Vim 4.0 can slow down the startup time noticeably. Until Vim supports dynamic loading, you can speed up the startup time by compiling two different versions of Vim: one with the GUI and one without the GUI and install both. Make sure you remove the link from $bindir/gvim to $bindir/vim when installing the GUI version, though.
If screen updating is your problem, you can run Vim in screen. screen is an ascii terminal multiplexer. The latest version can be found at <URL:ftp://ftp.uni-erlangen.de:/pub/utilities/screen >.
You can change some termcap values to send to the screen the proper codes to change some colors (providing your terminal supports color). Here are some examples of how to do this if you do ``:h unix'' but it seems as though they don't work all that well. But they help to understand what has to be done:
:set t_me=<Esc>[0;1;36m " normal mode (undoes t_mr and t_md) :set t_mr=<Esc>[0;1;33;44m " reverse (invert) mode :set t_md=<Esc>[1;33;41m " bold mode :set t_se=<Esc>[1;36;40m " standout end :set t_so=<Esc>[1;32;45m " standout mode :set t_ue=<Esc>[0;1;36m " underline end :set t_us=<Esc>[1;32m " underline mode start
Quoting Tony Nugent:
You can do some interesting things by putting ansi colour sequences into those capabilities. What's given here are just examples, and some combinations don't work very well. You need to discover for yourself a configuration that works. For example, end-modes need to switch everything back to normal as well as turn things off.Just load ~/.vimrc, play around with the values, save it and then see what it looks like by sourcing it (:so ~/.vimrc).
Don't forget to do things like ``:/<Ctrl-D>'' and ``:map'' to see all the different effects. And don't forget about the ``:set highlight='' string to fine-tune how the different capabilities are used.
BTW, something like this also works for DOS and Win32 Vims! So it should also work well with windows or any ansi- and vt100- compatible terminal mode capable of displaying colours (which includes all colour pc's). It doesn't work so well in plain old xterm's (YMMV - your milage may vary).
You can find a list of terminal codes here:
<URL:http://www.cs.utk.edu/~shuford/terminal_index.html >
<URL:ftp://cs.utk.edu/pub/shuford/terminal/ >
<URL:ftp://gatekeeper.dec.com/pub/DEC/termcaps >
It's not possible to use a CTRL-C in the {lhs}. You just can't map CTRL-C. The reason is that CTRL-C must always be available to break a running command.Allowing to map CTRL-C is very dangerous because it might then be impossible to get out of Vim. (Btw, disallowing to map CTRL-C is Vi compatible.) Btw, you *can* map 'Esc' in Insert mode - but then you will need to use CTRL-C to get back to normal-mode.
Q: How can I start vim without reading any setup files? A: "vim -u NONE"
Q: Can Vim be run on Windows98? A: Yes. Known users: Mike Bunker [email protected] Q: Can Vim be run on Windows2000? A: ???
WindowsNT Q: Why does ":w file" overwrite 'file' even though it it "read-only"? A: ???