I'm on Windows 10, update 1909, and I've resolved this by overriding high DPI settings for gVim to System(Enhanced). Setting GUI font size did not help.
Right click on gVim icon -> Properties -> Compatibility -> Change high DPI settings -> check box "Override high DPI scaling behavior" in the bottom of the dialog window and set "Scaling performed by:" to "...
The function you are looking for is fnameescape(). It will escape all special characters in a given string containing a path to a file to match the standard of the current operating system.
For more on this see :help fnameescape()
I think tuxproject.de is the way to go and I think, it will pick up Python dll, if they are in your path and are also 64bit. The easy way is to copy them to your .vim directory, to make sure vim will find them when trying to load them.
There is another alternative (and I really hope this will become official). We are trying to build binary Vims as part of ...
When I have to work on Windows (which is more often than I would like), I use Cygwin to get a terminal a little less crappy than the original Windows command line. Cygwin provides an environment which tries to be close to a Bash console with standard Linux commands, and of course it is far from being flawless.
See the project page of Cygwin. During the ...
This happens because when vertical splitting the window, vim needs to add a vertical scrollbar, which causes vim to recalculate the visual size and eventually makes vim jump to a different screen location. The current workaround is to :set guioptions-=r guioptions-=L
As of patch 8.0.1278, you can also use :set guioptions+=k to prevent Vim from ...
I'm aware this is a very old question but I recently found a good solution. After much frustration, I came across these ways to access the windows system clipboard by copying and pasting.
By copying, with vim version >= 8.0.1394, as noted in another answer https://vi.stackexchange.com/a/15190
let s:clip = '/mnt/c/Windows/System32/clip.exe'
Neovim looks for ~\AppData\Local\nvim\init.vim to run at startup.
If you want to create the suggested init.vim from :help nvim-from-vim, save the following instead:
Then you can save all your settings to ~\_vimrc just like you did with Vim.
See this answer and :help ...
Say hello to knowledge fragmentation: https://stackoverflow.com/q/6932702/520162 This question was already asked and answered on StackOverflow.
The key is to press CTRL and the key that is located where the ] lives on the US keyboard. I had the issue with a QUERTZ German keyboard and have to press CTRL-+
Compare: US keyboard:
As of Windows 10 Anniversary Update, you can use the Bash on Ubuntu terminal to run a Linux subsystem where you can apt install anything you're used to inside Ubuntu. Your Windows file system is mounted so you can use Vim inside the shell to edit your files.
Since 7.4, all your configuration files (even your vimrc) are expected to be in this directory:
But the name and location of that directory only matter to Vim. From Git's point of view, that directory could as well be /etc/foo/bar/ without any impact whatsoever.
put your vimrc and all your third-party scripts in %...
As stated on neovim wiki:
Windows support is (currently) experimental. To try it out, you need nvim.exe and a front-end such as Neovim-Qt.
However there isn't a list of all features that are missing or unstable. The best way to discover is actually installing and trying.
As on other vi/vim versions, you can use :w! to force the write, as long as you have permissions to override the read-only property.
For example, if you have set the file as read-only, the above will work. If Windows itself or an administrator has set it read-only, you will need another option.
As @dash-tom-bang commented, one good example is within ...
Thank you to @Christian Brabandt for linking this in the comments: https://www.reddit.com/r/vim/comments/7pmv3d/workflows_that_work/dskyram/
Works great. Just put the following in your vimrc and make sure to have vim version >= 8.0.1394
" WSL yank support
let s:clip = '/mnt/c/Windows/System32/clip.exe' " default location
PuTTY, like other high-color terminals, only supports a fixed color palette of 256 colors. GVIM can use the full 24-bit RGB color space; that's why you see "finer" nuances there.
As for attributes, GVIM offers undercurl, which is not present in any terminal, and free mixture of bold (depending on configuration shown with lighter color instead) and italic (...
On Windows, the configuration file of gVim is named:
It is placed in the installation directory, the default being:
C:\Program Files (x86)\Vim
To edit the file you first need to launch some text editor As Administrator.
And then open the above mentioned file.
Just add something similar to this:
In alternative to the maximized window, why do not gain more space for a full vim multiwindows editing experience with an autostart FULL SCREEN mode? ;-)
FULL SCREEN screenshot of the final result (= ALL THE VIDEO pixels capacity):
In my opinion that's better than a windows maximize: a complete FULL SCREEN (as I used to do with puTTY with ALT-Enter when ...
You need to install Python yourself on Windows.
If you type :version, you should see +python/dyn and +python3/dyn. On Windows, this means that Vim is compiled to dynamically load the Python DLL. You can read about this in :h python-dynamic. Depending on the versions you install, you may want to look at :h pythondll and :h pythonthreedll.
If you install ...
The user's runtime directory is $XDG_CONFIG_HOME/nvim. When $XDG_CONFIG_HOME isn't set (which is the typical case), then the default directory is ~/AppData/Local on Windows and ~/.config elsewhere.
OS | Vim | nvim
Windows | ~/vimfiles | ~/AppData/Local/nvim
*nix/macOS | ~/.vim | ~/.config/...
I was just looking this information up and I only found one x64 version not mentioned by Christian. Here's a summary of the interfaces each version supports today to give you an idea of how well they stay up to date:
Vim 7.4.1832 and x64
Interfaces: ActivePerl 5.22, ActiveTcl 8.6, LuaBinaries 5.3, Python 2.7, Python 3.4, Racket 6.4, ...
tl;dr: My path was using the an old Vim version, with v8.1.428 we have full 24-bit glorious colours in Vim in the Windows Console! See below for screenshots.
Err, so there was a basic mistake on my part. I still had my system environment path pointing to my Git SCM installation C:\Program Files\Git\usr\bin (which contains an older version of Vim) and on top ...
You can set the
options from within Vim to resize the window. For example:
You can add this to your vimrc file to do it automatically. This will work on gVim on any platform, and in most terminal emulators.
Related question: How do I get gvim to start maximised in Windows?
You're seeing the effects of the Windows File System Redirector. When you edit files in %ProgramFiles% without administrative rights / user account elevation (which isn't allowed in modern version of Windows), Windows redirects the file access to another location inside your user's home directory (to support legacy applications that were written to persist ...
All right, apparently the state is this: VIM on Windows supports python 2.7.9, not 2.7.11. It might work with 2.7.10, I did not test it.
Even though I compiled VIM on Windows with a reference to the 2.7.11 DLL, it suddenly worked when I tried swapping out 2.7.11 for 2.7.9
I'm not sure if I did something wrong with 2.7.11, and it actually does work, but I ...
It is distributed with Vim (as xxd.exe), along with diff.exe.
So it exists and should work on Windows. You don't need to install anything separately, as it is already bundled with Vim (at least in the versions available from vim.org).
Vim internal use of encoding (this settings is must if you like to use utf-8 or you would like to convert encoding from one to another). I strongly recommend to set this setting in _vimrc file (Windows equivalent of Linux .vimrc file). You can open your _vimrc file with command: :e $MYVIMRC
Bellow is actual setting ...
GVim is a 32-bit application and WSL must run on 64 bit. On Windows 10 you can use GVim with WSL if you add the following to your vimrc file:
set mouse= is the fix for the problem, with set t_BE= substituted in an xterm environment. The 'bug' these fixes solve was actually intended as a 'feature': creating an obstacle to pasting vi commands would be good if malicious code were somehow inserted onto user's clipboard.
Kudos to a guy named Elijah, on another message-board, who researched and solved ...
After you answered the question yourself, the focus shifted. It seems the Question is now "How can I prevent Vim from checking for $HOME/_vimrc?".
Try the following:
Create the file $USERPROFILE/vimrc with all your configuration.
Create the environment variable VIMINIT with the value source $USERPROFILE/vimrc.
On startup the variable VIMINIT is checked ...