95?
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.
the 16-bit DOS version updates the screen quickly, why would I want to run the Win32 version?
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.
menus, pasting from the clipboard, and so on become available?
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.
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?
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, velman@igate1.hac.com:
1. To get Vim to run in a window, instead of full screen, press Enter>. This toggles back and forth between full screen and a DOS window. 2. Issue the command ``:set paste''. 3. To paste something *into* Vim, put Vim in insert mode. 4. Put the text you want to paste on the windows clipboard. 5. Click the control box in the upper left of the Vim window. (This looks like a big minus sign). If you don't want to use the mouse, you can get this with Spacebar>. 6. On the resulting dropdown menu choose 'Edit'. 7. On the child dropdown menu choose 'Paste' 8. Issue the command ``:set nopaste''.
To copy something from the Vim window to the clipboard,
1. Select the control box to get the control drop down menu. 2. Select 'Edit'. 3. Select 'Mark'. 4. Using either the the keys or the mouse, select the part of the Vim window that you want to copy. To use the keys, use the arrow keys, and hold down shift to extend the selection. 5. When you've completed your selection, press ``Enter .'' The selection is now in the Windows clipboard. By the way, this can be any rectangular selection, for example columns 4-25 in rows 7-10. It can include anything in the Vim window: the output of a ``:!dir'', for example.
From Stan Brown stbrown@nacs.net: 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.
instead of just the letters?
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.