Is it possible to tell vim to save its viminfo file somewhere else?
Such as in the .vim folder
Try adding set viminfo+=n~/.vim/viminfo to your ~/.vimrc file. From :help 'viminfo':
n Name of the viminfo file. The name must immediately follow
the 'n'. Must be the last one! If the "-i" argument was
given when starting Vim, that file name overrides the one
given here with 'viminfo'. Environment variables are expanded
when opening the file, not when setting the option.
set viminfo='1000,nc:\\users\\abcdef\\_viminfo
This works for me in Windows 7.
I had a similar problem but had no write permission to my home folder (thus could not create the ~/.vimrc).
I solved it by modifying (through the Administrator) the _vimrc in C:\Program Files\VIM to include the line:
let $HOME = $USERPROFILE
I placed it at the beginning of the file and it worked well. Just in case someone comes across this question and this answer didn't work.
I know its quite a while now, but I am just mentioning this for future readers.
I was facing the same issue while trying to change the location for viminfo file in vimrc. At last setting the value of viminfofile option worked for me.
Added the following to my vimrc:
set viminfofile=D:\vim\viminfo
It works for me on windows with vim 8.2
TL;DR
This seems to be a bug in vim where set nocompatible is not idempotent and doesn't follow the principle of least astonishment.
As a workaround, either:
Ensure that you set nocompatible (or the equivalent set nocp) only once, and at the top of your vimrc.
Don't set it again if it's already set:
if &compatible | set nocompatible | endif " Avoid side effects if `nocp` already set
Explanation and bug illustration
From :help compatible (empahsis mine):
This is a special kind of option, because when it's set or reset,
other options are also changed as a side effect. CAREFUL: Setting or
resetting this option can have a lot of unexpected effects: Mappings
are interpreted in another way, undo behaves differently, etc. If you
set this option in your vimrc file, you should probably put it at the
very start.
Note that &viminfo is not listed in the side-effects, however the following lines clearly show the side effect upon &viminfo:
set nocompatible
set viminfo+=nWatch-my-viminfo-file-location-be-ignored
echom &viminfo
set nocompatible " do side effects even though nocomptible is already set
echom 'After 2nd "set nocompatible":'
echom &viminfo
Output:
'100,<50,s10,h,nWatch-my-viminfo-file-location-be-ignored
After 2nd "set nocompatible":
'100,<50,s10,h
vim --version | head -1
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 05 2016 16:48:20)
Resolution
I have raised two GitHub issues regarding this:
Undocumented "set nocompatible" side effect upon &viminfo
set nocompatible not idempotent - setting produces side effects when already set
See also Vi StackExchange's question: Can't move viminfo file - &viminfo reverts upon loading vim which I raised before seeing this one.
The ordering of settings in the .vimrc affects the use of :set viminfo. The setting of viminfo should be after the setting of nocompatible. After reordering my .vimrc, the above solution to have the viminfo file be located in the .vim directory worked for me.
In gvim8.2 on Windows10, following option works to change path of viminfo :
set viminfofile=$VIM/.viminfo
Write this in .vimrc .
It could to change viminfo file path to under the $VIM.
Related
I am new to nvim editor. i need help setting up my ~/.vimrc file. i have seen some tutorials and followed them. and came up with this:
> vim ~/.vimrc
have added this to my vimrc.
syntax on
set noerrorbells
set tabstop=4 softtabstop=4
set shiftwidth=4
set expandtab
set smartindent
set nu
and then source the file
:source %
the changes get applied instantly. but when i exit the file and open it again the changes disappear. if i source it again it works. is there any way i can make these changes permanent.
[note] : when i exit the file i used :x
UPDATE:
when i try to open ~/.config/nvim/init.vim using vim. i am getting this error.
E325: ATTENTION
Found a swap file by the name "~/.local/share/nvim/swap//%home%manoj%.config%nvi
m%init.vim.swp"
owned by: manoj dated: Wed Mar 31 16:01:46 2021
file name: ~manoj/.config/nvim/init.vim
modified: YES
user name: manoj host name: manoj
process ID: 15099
While opening file "/home/manoj/.config/nvim/init.vim"
CANNOT BE FOUND
(1) Another program may be editing the same file. If this is the case,
be careful not to end up with two different instances of the same
file when making changes. Quit, or continue with caution.
(2) An edit session for this file crashed.
If this is the case, use ":recover" or "vim -r /home/manoj/.config/nvim/init
.vim"
to recover the changes (see ":help recovery").
If you did this already, delete the swap file "/home/manoj/.local/share/nvim
/swap//%home%manoj%.config%nvim%init.vim.swp"
to avoid this message.
Swap file "~/.local/share/nvim/swap//%home%manoj%.config%nvim%init.vim.swp" alre
ady exists!
~/.vimrc is the default configuration file for vim. For neovim, simply copy the file to ~/.config/nvim/init.vim (You may need to create the nvim directory first).
Taken from the arch wiki, although the most info is in the official documentation.
in my ~/.config/nvim/init.vim, there are the line :
source ~/.vimrc
I change it to :
source ~/.vim/vimrc
and neovim (v0.6.1) use my ~/.vim/vimrc file settings
MacVim 8.0:
If there is no .vimrc file, set shows:
:set
--- Options ---
autoindent scroll=18 ttymouse=xterm2
helplang=en showmatch wrapmargin=10
langmenu=none ttyfast nowrapscan
backspace=indent,eol,start
fileencodings=ucs-bom,utf-8,default,latin1
pythondll=/usr/local/Frameworks/Python.framework/Versions/2.7/Python
pythonhome=/usr/local/Frameworks/Python.framework/Versions/2.7
If I create an empty .vimrc file, set shows:
set
--- Options ---
helplang=en scroll=18 ttymouse=xterm2
langmenu=none ttyfast
backspace=indent,eol,start
fileencodings=ucs-bom,utf-8,default,latin1
pythondll=/usr/local/Frameworks/Python.framework/Versions/2.7/Python
pythonhome=/usr/local/Frameworks/Python.framework/Versions/2.7
This differs from the first case in that autoindent, showmatch, and wrapscan are missing. Why is there a difference? These options do not seem to be set in /Applications/MacVim.app/Contents/Resources/vim/vimrc.
Starting vim with -u file is supposed to use file as the startup file. So if I remove the empty .vimrc--so now I have no .vimrc--and use -u emptyfile, where emptyfile is an empty file, I would expect that set would show what is listed immediately above. However, set shows something very different:
:set
--- Options ---
helplang=en scroll=18 ttyfast ttymouse=xterm
fileencodings=ucs-bom,utf-8,default,latin1
iskeyword=#,48-57,_,192-255
Why is this different from the previous case?
(Why do I care? Because I'm trying to figure out why an initialization file executes properly when it's .vimrc, but not when I run it with -u.)
Without a vimrc at any of the expected locations, Vim sources:
$VIM/vimrc
$VIMRUNTIME/defaults.vim
...
This is new in Vim 8.0. Before that version, Vim would only source $VIM/vimrc in this scenario. The reasoning behind that new feature was allegedly to provide more useful defaults to infrequent users without asking them to write their own vimrc.
See :help defaults.vim.
With a vimrc at one of the expected locations (assuming ~/.vimrc but it can be ~/.vim/vimrc), Vim sources:
$VIM/vimrc
$HOME/.vimrc
...
This is the optimal scenario for frequent users, experienced or not: you get the basic behavior plus all your fancy stuff.
When pointing Vim to a specific vimrc with -u, Vim only sources that specific vimrc.
This is the absolutist scenario that gives you complete control over Vim's settings. I wouldn't recommend it to inexperienced users.
I have found part of the answer. (I'll post it here for anyone with a similar question, but I don't expect upvotes for either the question or the answer.)
help initialization says, among other things:
If Vim was started with "-u filename", the file "filename" is used.
All following initializations until 4. are skipped. $MYVIMRC is not
set.
Most of what is between that point and 4. was not relevant to my situation; these are steps that occur only in special circumstances. However, one item between that point and 4. is:
b. For Unix, MS-DOS, MS-Windows, OS/2, VMS, Macintosh, RISC-OS and Amiga
the system vimrc file is read for initializations. The path of this
file is shown with the ":version" command.
So the system initialization file is not run when -u is used. (This still doesn't fully answer my first question, which mentions the system initialization file on my system.)
If I open a file in a current directory using netrw and then reopen the netrw using :Sexplore the netrw window opens below (I have splitbelow set), but the cursor remains in the file being edited and I cannot move to the netrw window using CTRL-W combinations.
Am I doing something wrong or is this a bug?
Steps to reproduce
run vim .
netrw opens, highlight a file in the current directory (let's say test.txt) and press Return, file test.txt opens
run :Sexplore cmd
netrw opens below but the cursor remains in the file opened previously.
My .vimrc
set nocompatible
set splitbelow
VIM version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Dec 8 2015 23:11:08)
MacOS X (unix) version
Included patches: 1-944
This is how it looks like:
I cannot reproduce with version 154a (use :echo g:loaded_netrwPlugin to check your netrw version).
Try with the latest version.
Edit:
It is possible that the problem is cause by some other plugin interference or settings. You could try following the approach described at Vim FAQ 2.5:
2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a
problem with my setup or with Vim? / Have I found a bug in Vim?
First, you need to find out, whether the error is in the actual
runtime files or any plugin that is distributed with Vim or whether it
is a simple side effect of any configuration option from your .vimrc
or .gvimrc. So first, start vim like this:
vim -u NONE -U NONE -N -i NONE
This starts Vim in nocompatible mode (-N), without reading your
viminfo file (-i NONE), without reading any configuration file (-u
NONE for not reading .vimrc file and -U NONE for not reading a .gvimrc
file) or even plugin.
(...)
If the error does not occur when starting Vim this way, then the
problem is either related to some plugin of yours or some setting in
one of your local setup files. You need to find out, what triggers the
error, you try starting Vim this way:
vim -u NONE -U NONE -N
If the error occurs, the problem is your .viminfo file. Simply delete
the viminfo file then. If the error does not occur, try:
vim -u ~/.vimrc --noplugin -N -i NONE
This will simply use your .vimrc as configuration file, but not load
any plugins. If the error occurs this time, the error is possibly
caused by some configuration option inside your .vimrc file. Depending
on the length of your vimrc file, it can be quite hard to trace the
origin within that file.
The best way is to add :finish command in the middle of your .vimrc.
Then restart again using the same command line. If the error still
occurs, the bug must be caused because of a setting in the first half
of your .vimrc. If it doesn't happen, the problematic setting must be
in the second half of your .vimrc. So move the :finish command to the
middle of that half, of which you know that triggers the error and
move your way along, until you find the problematic option. If your
.vimrc is 350 lines long, you need at a maximum 9 tries to find the
offending line (in practise, this can often be further reduced, since
often lines depend on each other).
Obviously you will have to load netrw manually (which can be done by sourcing plugin/netrwPlugin.vim -- if you are using some plugin manager you will have to move the plugin to ~/.vim/ or change your runtime path due to the autoload functions) and set nocompatible and splitbelow.
Actually there is an adapted version of this procedure in :help netrw-debug:
Step 2: assuming that you've installed the latest version of netrw,
check that your problem is really due to netrw. Create a file called
netrw.vimrc with the following contents:
set nocp
so $HOME/.vim/plugin/netrwPlugin.vim
Then run netrw as follows:
vim -u netrw.vimrc --noplugins [some path here]
Perform whatever
netrw commands you need to, and check that the problem is still
present. This procedure sidesteps any issues due to personal .vimrc
settings and other plugins. If the problem does not appear, then you
need to determine what setting in your .vimrc is causing the conflict
with netrw or which plugin.
Step 3: If the problem still is present, then get a debugging trace
from netrw:
(...)
I'm on a system (linux) that always recognizes cpp files (*.cc) as tcl files. I don't know what file type that is, but I wanted to override it. The correct syntax highlighting is chosen if I manually do :set ft=cpp. However, I'm having troubles setting that automatically and I don't want to use the modeline option. My own .vimrc doesn't interfere (same result if I rename it).
From the vim help (:help ftplugin-override)
*ftplugin-overrule*
If a global filetype plugin does not do exactly what you want, there are three
ways to change this:
1. Add a few settings.
You must create a new filetype plugin in a directory early in
'runtimepath'. For Unix, for example you could use this file:
vim ~/.vim/ftplugin/fortran.vim
You can set those settings and mappings that you would like to add. Note
that the global plugin will be loaded after this, it may overrule the
settings that you do here. If this is the case, you need to use one of the
following two methods.
I have used this option before on another machine and that worked. I've tried
<file> .vim/ftplugin/tcl.vim
set filetype=cpp
"au BufRead,BufNewFile * set filetype=cpp
The first line correctly sets the filetype (:set ft? returns cpp), but syntax highlighting is not the same as if I said :set ft=cpp. It's still the tcl syntax highlighting. The second line does nothing.
2. Make a copy of the plugin and change it.
You must put the copy in a directory early in 'runtimepath'. For Unix, for
example, you could do this:
cp $VIMRUNTIME/ftplugin/fortran.vim ~/.vim/ftplugin/fortran.vim
Then you can edit the copied file to your liking. Since the b:did_ftplugin
variable will be set, the global plugin will not be loaded.
A disadvantage of this method is that when the distributed plugin gets
improved, you will have to copy and modify it again.
There seems to be no file in my $VIMRUNTIME directory /usr/share/vim/vim72/ftplugin/ called tcl.vim.
3. Overrule the settings after loading the global plugin.
You must create a new filetype plugin in a directory from the end of
'runtimepath'. For Unix, for example, you could use this file:
vim ~/.vim/after/ftplugin/fortran.vim
In this file you can change just those settings that you want to change.
Has the same effect as 1. Is there anything else I can try? Thanks a lot in advance.
cpp is the default filetype for *.cc and *.cpp files.
The tcl filetype is only set for *.tcl, *.tk, *.itcl, *.itk and *.jacl.
I see no reason why Vim would default to tcl when loading a *.cc file but you could check if theses files are installed:
/usr/share/vim/vim7x/ftplugin/cpp.vim
/usr/share/vim/vim7x/indent/cpp.vim
/usr/share/vim/vim7x/syntax/cpp.vim
and if the correct checks are done in:
/usr/shhare/vim/vim7x/filetype.vim
Are you the only person working on this machine? Do you use modelines?
I've got set formatoptions=cqn in my vimrc, but for some reason it doesn't stick. It seems like Vim is reverting to the default (fo=tcq) at some point… But I can't figure out why. Running -V100/tmp/log just gives me:
formatoptions=tcq
Last set from ~/.vimrc
With no useful context.
So, is there any way to make formatoptions stick? Or do I just need to create an autocmd to reset it each time a new file is loaded?
Edit
Using :verbose set formatoptions shows this:
formatoptions=tcq
Last set from ~/.vimrc
However, the only reference to fo or formatoptions in my ~/.vimrc is set formatoptions+=cqn.
This behavior is because of C file plugin in VIM. Since file plugin is loaded after loading .vimrc, the settings in .vimrc are overwritten.
The solution given by David Wolever seems to be the best option.
Add the following line in .vimrc:
autocmd BufNewFile,BufRead * setlocal formatoptions+=cqn
...instead of the normal set formatoptions command.
I ran across this problem too. I had project-specific configurations something like
autocmd BufRead,BufNewFile project/*.c setlocal formatoptions-=cro
However, set fo? showed formatoptions=croql. Turns out, I needed BufWinEnter instead of BufRead:
After a buffer is displayed in a window. This
can be when the buffer is loaded (after
processing the modelines) or when a hidden
buffer is displayed in a window (and is no
longer hidden).
Does not happen for :split without
arguments, since you keep editing the same
buffer, or ":split" with a file that's already
open in a window, because it re-uses an
existing buffer. But it does happen for a
":split" with the name of the current buffer,
since it reloads that buffer.
So this works
autocmd BufWinEnter,BufNewFile project/*.c setlocal formatoptions-=cro
According to the vim documentation on formatoptions:
NOTE: This option is set to the Vi
default value when 'compatible' is
set and to the Vim default value when
'compatible' is reset.
So if the value of compatible is changing along the way, that could be causing the issue you're seeing.
I does sound like some file either sourced from your .vimrc or plugins are changing that value.
Something to try to pinpoint it is
start vim without sourcing anything, use
vim -u NONE
Using NORC skipps .vimrc but loads plugins
Check :help --noplugin to read about various startup-options that controls the sourcing.
--noplugin Skip loading plugins. Resets the 'loadplugins' option.
{not in Vi}
Note that the |-u| argument may also disable loading plugins:
argument load vimrc files load plugins ~
(nothing) yes yes
-u NONE no no
-u NORC no yes
--noplugin yes no
Perhaps this might be useful as well (from help: :set):
When 'verbose' is non-zero, displaying an option value will also tell where it
was last set. Example: >
:verbose set shiftwidth cindent?
< shiftwidth=4 ~
Last set from modeline ~
cindent ~
Last set from /usr/local/share/vim/vim60/ftplugin/c.vim ~
perhaps... :-)
Edit
Are you using compatible? From help: formatoptions
NOTE: This option is set to the Vi default value when 'compatible' is
set and to the Vim default value when 'compatible' is reset.
Found in /usr/share/vim/vim74/ftplugin/vim.vim:
" Set 'formatoptions' to break comment lines but not other lines,<br>
" and insert the comment leader when hitting <CR> or using "o".<br>
setlocal fo-=t fo+=croql
Remove it. Then all things done.