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.)
Related
I'm trying to override 'w' in vim so it would call an external program and filter the buffer instead of writing to a file. There are very good examples across the internet about how to do that. I tried one from vim.wikia.com, but vim always complains with E488: Trailing characters. This is the command in my vimrc:
cabbrev w <c-r>=(getcmdtype()==':' && getcmdpos()==1 ? 'W' : 'w')<CR>
I'm not very familiar with vim script. I tried removing <CR> from the end of the line with no luck.
UPDATE
Since I want to run vim as customized as possible I run it with the -u flag. I noticed that vim behaves differently when using that flag compared to running it without it
With the -u flag the expanded abbreviation is what needs to be evaluated as code.
Without the flag, the abbreviation is what it is intended to be (here I enter the cabbrev rule from vim's prompt)
Regarding the -u flag vim's man page says this:
-u {vimrc} Use the commands in the file {vimrc} for
initializations. All the other initializations
are skipped. Use this to edit a special kind of files. It can also be used to skip all
initializations by giving the name "NONE". See ":help initialization" within vim for more
details.
Apparently when this flag is used the initialization from
vim /etc/vimrc is not performed and there I found this option:
set nocompatible
vim's help about compatible option:
This option has the effect of making Vim either more Vi-compatible, or
make Vim behave in a more useful way. 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.
...
When a vimrc or gvimrc file is found while Vim is starting up,
this option is switched off, and all options that have not been
modified will be set to the Vim defaults. Effectively, this means
that when a vimrc or gvimrc file exists, Vim will use the Vim
defaults, otherwise it will use the Vi defaults. (Note: This doesn't
happen for the system-wide vimrc or gvimrc file, nor for a file given
with the -u argument).
set nocompatible makes the cabbrev syntax from the question work
I tried to install Conque-Shell via Vundle, and when I input :ConqueTerm bash in vim, it showed 'ConqueTerm: Not an edit command'. I thought there was something wrong with my path. But I did write set rtp+=~/.vim/bundle/vundle in my .gvimrc. And the configure of Vundle is at the beginning of the .gvimrc.
I copied the .vim/bundle/Conque-Shell/plugin/conque_term.vim to .vim/plugin/conque_term.vim and then it worked.
So, is there anything wrong with my .gvimrc?? Thanks!
My .gvimrc: https://gist.github.com/guori12321/5506991
If you observe the output of :scriptnames (the list of scripts sourced during startup), you'll note that .gvimrc comes last, after .vimrc and the plugins. Therefore, any changes to the 'runtimepath' there are too late; plugins (like ConqueTerm) have already been loaded. You can read more about the startup process at :help initialization.
Even if you only use the GUI GVIM, put the common settings into ~/.vimrc; the ~/.gvimrc file is for GUI-only stuff that doesn't apply to the terminal Vim, e.g. setting 'guifont' and similar options.
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.
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.