This is os_win32.txt in view mode; [Download] [Up]
*os_win32.txt* For Vim version 5.0f. Last modification: 1997 Apr 20
VIM REFERENCE MANUAL by George Reilly
This file documents the idiosyncrasies of the Win32 version of Vim.
The Win32 version was written by George V. Reilly <gvr@halcyon.com>.
The original Windows NT port was done by Roger Knobbe <RogerK@wonderware.com>.
The Win32 version of Vim works on both Windows NT and Windows 95. It is a
console-mode application (i.e., it runs in a command prompt window or a "DOS
box"). It is not a full-fledged Windows GUI application, although it may
become one some day. It will not run in the Win32s subsystem in Windows
3.1; use the 32-bit DOS version of Vim instead. See |os_msdos.txt|.
KNOWN PROBLEMS
There are a few known problems with running the Win32 Vim on Windows 95.
Comments from somebody working at Microsoft: "Win95 console support has always
been and will always be flaky".
- Dead key support doesn't work.
- Resizing the window with ":set columns=nn rows=n" works, but executing
external commands may cause the system to crash.
If this bothers you, use the 32 bit MS-DOS version.
- When doing filename completion, matches for the short filename will also be
found. But this will result in the corresponding long filename. For
example, if you have the long file name "this_is_a_test" with the short
filename "this_i~1", the command ":e *1" will start editing
"this_is_a_test".
LOCATION OF DOCUMENTATION and VIMRC FILE
You should set the environment variable "VIM" to the directory where the Vim
documentation files are. If "VIM" is used but not defined, "HOME" is tried
too.
If the HOME environment variable is not set, the value "C:/" is used as a
default.
The default help filename is "$VIM\doc\help.txt". If the environment variable
$VIM is not defined or the file is not found, the Win32 search path is used to
search for the file "help.txt". If you do not want to put "help.txt" in your
search path, use the command ":set helpfile=pathname" to tell Vim where the
help file is. Also see |$VIM| and |'helpfile'|.
Vim will look for initializations in eight places. The first that is found
is used and the others are ignored. The order is:
- The environment variable VIMINIT
- The file "$VIM/_vimrc"
- The file "$HOME/_vimrc"
- The file "$VIM/.vimrc"
- The file "$HOME/.vimrc"
- The environment variable EXINIT
- The file "$VIM/_exrc"
- The file "$HOME/_exrc"
USING BACKSLASHES
Using backslashes in file names can be a problem. Vi halves the number of
backslashes for some commands. Vim is a bit more tolerant and backslashes
are not removed from a file name, so ":e c:\foo\bar" works as expected. But
when a backslash is used before a special character (space, comma, backslash,
etc.), it is removed. Use slashes to avoid problems: ":e c:/foo/bar" works
fine. Vim will replace the slashes with backslashes internally, to avoid
problems with some MS-DOS programs and Win32 programs.
USING COLORS
You can set the color used in five modes with nine termcap options. Which of
the five modes is used for which action depends on the |'highlight'| option.
":set t_mr=^V^[\|xxm" start of invert mode
":set t_md=^V^[\|xxm" start of bold mode
":set t_me=^V^[\|xxm" back to normal text
":set t_so=^V^[\|xxm" start of standout mode
":set t_se=^V^[\|xxm" back to normal text
":set t_us=^V^[\|xxm" start of underline mode
":set t_ue=^V^[\|xxm" back to normal text
":set t_ZH=^V^[\|xxm" start of italics mode
":set t_ZR=^V^[\|xxm" back to normal text
^V is CTRL-V
^[ is <Esc>
xx must be replaced with a decimal code, which is the foreground color number
and background color number added together:
COLOR FOREGROUND BACKGROUND
black 0 0
blue 1 16
green 2 32
cyan 3 48
red 4 64
magenta 5 80
brown 6 96
lightgray 7 112
darkgray 8 128
lightblue 9 144
lightgreen 10 160
lighcyan 11 176
lightred 12 192
lightmagenta 13 208
yellow 14 224
white 15 240
When you use 0, the color is reset to the one used when you started Vim
(usually 7, lightgray on black, but you can override this in NT. If you have
overridden the default colors in a command prompt, you may need to adjust
some of the highlight colors in your vimrc---see below).
The defaults for the various highlight modes are:
t_mr 112 reverse mode: black text (0) on lightgray (112)
t_md 63 bold mode: white text (15) on cyan (48)
t_me 0 normal mode (revert to default)
t_so 31 standout mode: white (15) text on blue (16)
t_se 0 standout mode end (revert to default)
t_czh 225 italic mode: blue text (1) on yellow (224)
t_czr 0 italic mode end (revert to default)
t_us 67 underline mode: cyan text (3) on red (64)
t_ue 0 underline mode end (revert to default)
These colors were chosen because they also look good when using an inverted
display, but you can change them to your liking.
Example:
:set t_mr=^V^[\|97m " start of invert mode: blue (1) on brown (96)
:set t_md=^V^[\|67m " start of bold mode: cyan (3) on red (64)
:set t_me=^V^[\|112m " back to normal mode: black (0) on light gray (112)
:set t_so=^V^[\|37m " start of standout mode: magenta (5) on green (32)
:set t_se=^V^[\|112m " back to normal mode: black (0) on light gray (112)
TEXTMODE or NON-MS-DOS FILES
If the "tx" (textmode) option is set (which is the default), Vim will accept
a single <NL> or a <CR><NL> pair for end-of-line. When writing a file, Vim
will use <CR><NL>. Thus, if you edit a file and write it, <NL> is replaced
with <CR><NL>. If the "tx" option is not set, a single <NL> will be used
for end-of-line. A <CR> will be shown as ^M. You can use Vim to replace
<NL> with <CR><NL> by reading in any mode and writing in text mode (":se
tx"). You can use Vim to replace <CR><NL> with <NL> by reading in text mode
and writing in non-text mode (":se notx"). 'textmode' is set automatically
when 'textauto' is on (which is the default), so you don't really have to
worry about what you are doing. |'textmode'| |'textauto'|
If you want to edit a script file or a binary file, you should reset the
'textmode' and 'textauto' options before loading the file. Script files and
binary files may contain single <NL> characters which would be replaced with
<CR><NL>. You can reset 'textmode' and 'textauto' automatically by starting
Vim with the "-b" (binary) option.
:CD COMMAND
The ":cd" command recognizes the drive specifier and changes the current
drive. Use ":cd c:" to make drive C the active drive. Use ":cd d:\foo" to go
to the directory "foo" in the root of drive D. UNC names are also recognized;
e.g., ":cd \\server\share\dir". |:cd|
INTERRUPTING
Use CTRL-Break instead of CTRL-C to interrupt searches. The CTRL-C is not
detected until a key is read.
TEMP FILES
Temporary files (for filtering) are put in the first directory in the next
list that exists and where a file can be created:
$TMP
$TEMP
C:\TMP
C:\TEMP
current directory
SHELL OPTION DEFAULT
*win32_shell*
The default for the 'sh' ('shell') option is "command.com" on Windows 95 and
"cmd.exe" on Windows NT. If SHELL is defined, it is used instead, and if
SHELL is not defined but COMSPEC is, COMPSPEC is used. External commands are
started with "<shell> /c <command_name>". Typing CTRL-Z starts a new
command subshell. Return to Vim with "exit". |'shell'| |CTRL-Z|
If you are running a third-party shell, you may need to set the
|'shellcmdflag'| ('shcf') and |'shellquote'| ('shq') options. For example,
with the MKS Korn shell or with bash, the values of the options should be:
'shellcmdflag' -c
'shellquote' "
This will start the shell as
<shell> -c "<command name>"
"-c" is needed in place of "/c" and double quotes are needed around the
command passed to the shell. Vim will check for the presence of "sh" anywhere
in the 'shell' option. If it is present, the 'shellcmdflag' and 'shellquote'
option will be set to "-c" and "\"".
TERM OPTION DEFAULT
*win32_term*
The only kind of terminal type that the Win32 version of Vim understands is
"win32", which is built-in. If you set 'term' to anything else, you will
probably get very strange behaviour from Vim. Therefore the default value of
'term' is not obtained from the environment variable "TERM".
RESTORE SCREEN CONTENTS
When 'restorescreen' is set (which is the default), Vim will restore the
original contents of the console when exiting or when executing external
commands. If you don't want this, use ":set nors". |'restorescreen'|
COMPILING
Vim for Win32 compiles with the Microsoft Visual C++ 2.0 compiler and later,
and with the Borland C++ 4.5 32-bit compiler and later. It compiles on
Windows 95 and all four NT platforms: i386, Alpha, MIPS, and PowerPC. The
NT/i386 and the Windows 95 binaries are identical. Use Makefile.w32 to
compile with Visual C++ and Makefile.b32 to compile with Borland C++.
The Win32 binary was compiled with Visual C++ version 4.0, using Makefile.w32.
Other compilers should also work. If you get all kinds of strange error
messages when compiling (you shouldn't with the Microsoft or Borland 32-bit
compilers), try adding <CR> characters at the end of each line. This can be
done with the addcr program: "nmake -f makefile.w32 addcr". This will compile
addcr.c to addcr.exe and then execute the addcr.bat file. Sometimes this
fails. In that case, execute the addcr.bat file from the DOS prompt.
USING THE MOUSE
The Win32 version of Vim supports using the mouse. If you have a two-button
mouse, the middle button can be emulated by pressing both left and right
buttons simultaneously. |mouse_using|
WIN32 FAQ *win32_faq*
Q. Why does the Win32 version of Vim update the screen so slowly on Windows 95?
A. 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.
WARNING: Changing 'columns' may make Windows 95 crash while updating the
window (complaints --> Microsoft). Since this mostly works, this has not
been disabled, but be careful with changing 'columns'.
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.
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.
Q. So if the Win32 version updates the screen so slowly on Windows 95 and the
16-bit DOS version updates the screen quickly, why would I want to run the
Win32 version?
A. 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 do big changes 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.
Q. And what about the 16-bit DOS version versus the Win32 version on NT?
A. 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 does when
running on NT. All of the above disadvantages apply. Finally, 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.
Q. Why can't I paste into Vim when running Windows 95?
A. 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. |'paste'|
Q. How do I type dead keys on Windows 95?
(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.)
A. You don't. The console mode input routines simply do not work correctly in
Windows 95, and I 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. |digraphs|
Alternatively, you can try one of the DOS versions of Vim where dead keys
reportedly do work.
Q. How do I type dead keys on Windows NT?
A. Dead keys work on NT 3.51. Just type them as you would in any other
application.
On NT 4.0, you need to make sure that the default locale (set in the
Keyboard part of the Control Panel) is the same as the currently active
locale. Otherwise the NT code will get confused and crash! This is a NT
4.0 problem, not really a Vim problem.
Q. When will a real GUI version of Vim (gvim) for Win32 with scrollbars,
menus, pasting from the clipboard, and so on become available?
A. A few months after Vim 4.0 is released. Apart from the features you
might expect in gvim (see |gui.txt|), it is expected that a real GUI
version will also be able to handle dead keys correctly and that the
problems with external commands will be a thing of the past.
Q. I'm using Vim to edit a symbolically linked file on a Unix NFS file server.
When I write the file, Vim does not "write through" the symlink. Instead,
it deletes the symbolic link and creates a new file in its place. Why?
A. 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" |'writebackup'|
Q. How do I get to see the output of ":make" while it's running?
A. Basically what you need is to put a tee program that will copy its input
(the output from make) to both stdout and to the errorfile. You can find a
copy of tee (and a number of other GNU tools tools) at
ftp://ftp.cc.utexas.edu/microlib/nt/gnu Alternatively, try the more recent
Cygnus version of the GNU tools at http://www.cygnus.com/misc/gnu-win32
You might also find useful stuff at Chris Szurgot's Virtual Unix site,
http://www.itribe.net/virtunix And Microsoft has some Unix-style tools at
http://www.microsoft.com/ntserver/tools/Maintnce.htm
When you do get a copy of tee, you'll need to add
set shellpipe=\|\ tee
to your _vimrc.
Q. I'm storing files on a remote machine that works with VisionFS, and files
disappear!
A. VisionFS can't handle certain dot (.) three letter extension file names.
SCO declares this behavior required for backwards compatibility with 16bit
DOS/Windows environments. The two commands below demonstrate the behavior:
echo Hello > file.bat~
dir > file.bat
The result is that the "dir" command updates the "file.bat~" file, instead
of creating a new "file.bat" file. This same behavior is exhibited in VIM
when editing an existing file named "foo.bat" because the default behavior
of VIM is to create a temporary file with a '~' character appended to the
name. When the file is written, it winds up being deleted.
Solution: Add this command to your _vimrc file:
set backupext=.temporary
vim:ts=8:sw=8:tw=78:fo=tcq2:
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.