I have been using Vim casually for around 3 years (mostly for git commit messages) and recently started using it exclusively for text editing and coding while I work my way through a series of intermediate tutorials and resources. Up until a few weeks ago, I primarily used either Vim, NeoVim or iVim (on iOS).
Recently I installed MacVim and started using it exclusively when I'm working in iTerm on a Mac. I have noticed some differences in the way .swp files are created and managed. In the other versions of Vim that I have used, .swp files are only created when I have a file open in more than one instance of Vim at the same time. It seems that MacVim creates .swp files for every open file (I'm guessing for backup/restore purposes). MacVim also seems to put .swp files into the working directory. I don't recall other versions of Vim doing this but it recently led me to add *.swp to my global Git ignore settings.
Before drafting this question I did a quick search for: vim macvim swp files and found one result that gave me a few ideas on how to work around one of the issues that I've noticed:
Vim Swap Files Not Deleting
I also found this post that gives the impression that the following settings are involved:
backup / nobackup
writebackup / nowritebackup
swapfile /noswapfile
But this doesn't really answer my question, which is "What is different?". I am editing my .vimrc regularly and would like to add in the appropriate settings to get the same behavior in MacVim by default (while also understanding what I am adding). What is unique about the way MacVim is setup related to swap files? Is there a specific combination of the three settings mentioned above or are more settings involved? How can I set up the same default behavior I have noticed in Vim, NeoVim, and iVim?
I have read the MacVim FAQ and Troubleshooting Guide but didn't find any relevant information.
The default location for a swap file is determined by :help 'directory'. Given the default value, Vim will try the directory of the file for which the swap file is created first, appending the .swp extension. If it can't create the swap file there, it will try the next location in 'directory':
The file:
_posts/2018-07-31-npm-201.markdown
The swap-file:
_posts/2018-07-31-npm-201.markdown.swp
If a swap file already exists for a file you are trying to edit and you decide to edit it anyway, another swap file is created at the same location, with a different extension: .swo, .swn, etc.
What I described above is the normal, expected, behaviour. And that's how MacVim works.
In the other versions of Vim that I have used, .swp files are only created when I have a file open in more than one instance of Vim at the same time.
Those "versions of Vim" are either:
broken,
weirdly configured,
not Vim.
It seems that MacVim creates .swp files for every open file (I'm guessing for backup/restore purposes).
You guessed right, and yes, that's the expected behaviour in every Vim.
MacVim also seems to put .swp files into the working directory.
If the file is in the working directory it's normal. If it's not, the working directory may be part of 'directory'. If it's not, you have found a bug.
I don't recall other versions of Vim doing this but it recently led me to add *.swp to my global Git ignore settings.
It's very common to have a Vim section in there.
Related
I like Vim as my mergetool and difftool. Whenever it runs (usually from git), it saves the files view states at ~/.vim/view folder, so when back to edition, they show up with diffmode on and have weird borders. Having to disable them manually or run rm ~/.vim/view/* outside Vim and reopen the files fixes it, but seems odd. How to prevent these tools from saving missconfigured view files?
[edit, more info about my setup]:
Very raw Vim. No plugins. No mappings. Only a bunch of random convenience tweaks on .vimrc (that I believe have nothing to do with the question: personal backup of .vimrc on GitHub). That is, as #filbranden points out, it might be possible to make an if statement to differentiate a diff session from others, and only save view files when not diffing. I am afraid not to know enough about vim script at this point.
I'm wondering whether I can change 'colorscheme' to point to different directory.(rather than default) since I want to set my all my color schemes in vimrc file with my own directory.
In My MacOS, the default directory are in /usr/local/share/vim/vim80/colors
You are supposed to put colorschemes in ~/.vim/colors/.
Create that directory if it doesn't exist and stay away from /usr/local/share/vim/.
As #romainl pointed out, keep your hands off the system-wide directories. Just because Vim's default stuff gets installed under /usr/local/share/vim, this doesn't mean that your personal extensions and customizations should be in there as well. You'll provoke problems when upgrading or reinstalling Vim.
If the suggested default location (~/.vim/colors/) doesn't suit you, you can add additional directories to 'runtimepath' (early enough; i.e. in your ~/.vimrc). For colorschemes, the direct directory has to be colors, though. To work around that, you'd have to use filesystem links to create an alias.
I just discovered keithn/vsvimguide for using VsVim with Resharper and added some useful key-mappings that use Resharper's functionality to a new _vsvimrc file I created.
Unfortunately, all my settings in my _vimrc which I use for gVim/vim elsewhere are no longer loaded. Is there a good way to not have to dual maintain my settings in two files? Perhaps a conditional I can use to check if I'm running inside Visual Studio? I'm assuming you can't load two settings files in VsVim.
glad you found it useful, I keep meaning to update it as I've changed around a bunch of how I use vsvim and resharper.
But to your question, you can load files with source which is a Vim standard way of loading files (you can :source <file> ) but in your vs vim file just put
source <path to vimrc>
you can source any other files you like into your .vsvimrc you can do the same in your actual vim config as well, so you could break out certain things into a "common" file if you wanted as well
I noticed that for whatever reason, my _vimrc wasn't being loaded this morning. I keep my entire vim directory saved to my Google Drive to the location I specify in my _vimrc. I didn't worry about it since I'd recently backed it up, but now when I dump it into my vim folder, whenever I start up gVim, it looks like it renames it to _vimrc.2014.
I can't find anything about this behavior, is it normal? It doesn't really affect me too much since it still gets source, but I just want to know why it's doing that.
Vim certainly is not doing this. I'm not certain it's causing YOUR problem, but Google Drive has problems replacing files with a new file of the same name. Under the hood, that is exactly what Vim is doing when it writes a file with default settings. See https://groups.google.com/d/topic/vim_use/jkw_nnHz9cE/discussion : you can use either the 'backupskip' or 'writebackup' options to force Vim to write the file directly instead of replacing it with a new file when editing inside your Google Drive folder. I'm using this line in my .vimrc to accomplish the task:
let &backupskip.=','.expand('$HOME/Google\ Drive/').'*'
I'm thinking about setting the following in vimrc
set autochdir
In vim.wikia.com it states that
...Unfortunately, when this option is set some plugins may not work
correctly if they make assumptions about the current directory....
Am I better just changing the working directory manually when required? Which plugins will not work properly when using autochdir?
I've been using :set autochdir since I've started with Vim in 2002, I use a lot of plugins, but I haven't experienced many problems. (And those problems were rather easy to fix; I think I've sent some such patches to plugin authors.)
In the end, it greatly depends on the individual plugins. Don't be afraid and just try it; it's trivial to switch back, anyway. Look out for problems with plugins that create new buffers or access / navigate to other buffers, especially when those are distributed over different directories. Problems ususally manifest themselves into the wrong buffer (or an empty one in the wrong directory) being opened.