Is there any methodology to organize the content of .vimrc in multiple files?
Currently my .vimrc has everything: Plugs statement, remaps, sets,functions,mapleader, custom plugins configuration, autogroup, etc.
I would like to organize in multiple files, perhaps by language.
Thank you!
You could split the contents of .vimrc into different files. Then source those files from within vimrc. Example:
" File: vimrc
" Author: Jonh Doe
" Options, commands, and auto commands
runtime settings.vim
" Maps
runtime maps.vim
" Functions
runtime functions.vim
" Plugin settings
runtime plug-settings.vim
Filetype-specific settings should be stored under ~/.vim/ftplugin, or less commonly, under ~/.vim/after/ftplugin. For example, html settings should be in ~/.vim/ftplugin/html.vim.
I suggest to take a look at vimrcs of experienced vim users. This repository should be a good starting point.
After your ~/.vimrc, Vim starts sourcing the plugin/ scripts. For your own mappings and custom commands, you can just place them anywhere in there, e.g. ~/.vim/plugin/MySuperCommand.vim and ~/.vim/plugin/MyLifeSaverMappings.vim.
For customization of other plugins, or Vim options that influence the behavior of plugins, it is crucial that these execute before the plugin(s). By using the ~/.vimrc (the general recommendation), this is ensured automatically. You can explicitly :runtime the scripts from your ~/.vimrc, as per #Sergio's answer, or define them as plugin scripts, too, but ensure that they run first:
If you install plugins the traditional way (in ~/.vim/plugin/), you can use the script naming (e.g. 00MyStuff.vim) to influence loading order.
If you use pack plugins, or a package manager, just ensure that your own plugin directory comes first in the 'runtimepath'.
The :scriptnames command is a valuable troubleshooting tool to verify that the script loading order is correct.
I have recently started using vim and I really like it. I have added a few easy mappings in my vimrc file.
But the problem is I get to use a lot of remote machines a lot of time and I can't copy my vimrc on to them but most of the times I won't have enough permissions to do that.
So, I was wondering if there is any way I can put all my vim mappings in a file and tell vim to run it every time it loads, just like a vimrc?
The action that is "parsing" the .vimrc is called source.
In runtime, you can reapply/reparse your .vimrc by using
:source ~/.vimrc
So if you can somehow copy your .vimrc, even if not in your home, but a folder like /tmp you should be able to source it from there, with
:source /tmp/.vimrc
This question has more details and solutions.
One option would be to specify an alternative .vimrc file while launching the program.
The vim man pages has this to say about specifying a vimrc file:
-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.
Note that this option overrides the default vimrc file, so you'll have to specify all of your settings/options in this file.
As was mentioned in another answer, you can place your custom vimrc file anywhere you want (or have access to) and then specify the the -u option with the path to your vimrc file.
You could even combine this method with managing your custom vimrc file in an online version control system (like github) - this way you will be able to wget your file from the web instead of having to manually copy it from machine to machine.
I am trying to update my Vim configuration scripts. There are a number of sub-directories in my ~/.vim directory and I'm not sure the specifics of what they do, nor why there are some that seem to be redundant.
Here is what my ~/.vim directory tree looks like
|-after
|---ftplugin
|---syntax
|-autoload
|-compiler
|-doc
|-ftplugin
|---latex-suite
|-----dictionaries
|-----macros
|-----packages
|-----templates
|---python
|-indent
|-plugin
|-spell
|-syntax
Now for the specific questions.
What goes in plugin vs ftplugin?
What is the difference between plugin and autoload?
When should I put something in after/... instead of in the directories directly under ~/.vim?
Whatever goes into plugin is loaded whenever vim starts whereas what you put in ftplugin is only loaded for the specific filetype it corresponds to (so if you have a folder there called python all the files there will be loaded when you open a python file.
In autoload you should have the functions corresponding to the the scripts defined in plugin. The functions here will only be loaded when called by the first time.
In after you should put settings that you want to change from the normal plugin loading.
As an example suppose you like the settings that some plugin for latex gives you, but it redefined a mapping that you had in your .vimrc. You can revert this with autocommands or by putting the correct definitions in after.
I think this would explain exactly what each folder does: http://learnvimscriptthehardway.stevelosh.com/chapters/42.html
Also might want to check :h runtimepath.
Hope this helps. :)
All those directories are part of the runtimepath. Try :h runtimepath and it will link you to your answers:
Check :h write-plugin
Check :h autoload-functions
after/... scripts are executed last, so they can override settings of earlier scripts. You can read more about this in :h runtimepath.
I use CVS to sync my config files between different PCs, including my $HOME/.vim folder.
But there is a problem. CVS likes to leave old copies of files in .vim/plugin/CVS/Base/ and Vim thinks it should load these files. I want vim to ignore them!
You can use SourceCmd for this case:
augroup ForbidCVS
autocmd!
autocmd SourceCmd */CVS/* :" Do nothing
augroup END
At the bottom of $HOME/.vimrc add:
" Disable normal auto-loading of plugins
set noloadplugins
" Now load just the plugins we want
runtime! plugin/*.vim
This differs from the default behaviour which usually loads scripts from plugin/ and all its subfolders. I suspect most users do not make sub-folders. For users that do, this won't work!
An easy way to share your .vim and .vimrc across multiple computers is to put both on dropbox and symlink them to the $HOME directory of each computer you work on. No CVS required, and any change you make to your .vimrc for example, is immediately available to all other computers.
Another cool tip is to use the vim gsession plugin to create global session files stored to your .vim directory. So if you create a session on one computer, it is also available to all the others.
How do I specify Vim settings for all files under the current directory?
The ideal solution would be if Vim searched for and read a .vimrc in the current directory before searching for ~/.vimrc, and apply the settings there for the entire tree.
I've seen a plugin, but this means the applied settings aren't transparent since they require the plugin to be installed. In contrast, a modeline is transparent since regardless of a user's vimrc or specific vim invocation the modeline settings will be applied for that file.
Things I tried are
placing a .vimrc in the working directory
:so vimrc in the modeline.
I suppose both don't work for security reasons. I don't need the full power of a vimrc; being bound to settings acceptable by a modeline would suffice. My goal is to make it easier for vimmers to adopt coding standards in a project.
You can put something like this in $VIM/vimrc
autocmd BufNewFile,BufRead /path/to/files/* set nowrap tabstop=4 shiftwidth=4
I'd strongly suggest not using set exrc
Even with set secure, under *nix, vim will still run autocommands, shell, et al, if you own the file. So if you happend to edit a file in that tarball I sent you with a .vimrc containing:
autocmd BufEnter * :silent! !echo rm -rf ~/
you'll probably be less amused than I will.
I'm an advocate of the plugin way.
For several reasons:
Modelines are particularly limited: we can't set variables (that tunes other (ft)plugins, like "should the braces of the for-snippet be on a newline ?"), or call function from them (I don't limit myself to coding standards, I also set the makefile to use depending on the current directory)
DRY: with modelines, a setting needs to be repeated in every file, if there are too many things to set or tunings to change, it will quickly become difficult to maintain, moreover, it will require the use of a template-expander plugin (which you should consider if you have several vimmers in your project).
Not every one uses vim to develop. I don't want to be bothered by other people editor settings, why should I parasite theirs?
It's easier to ask vimmers to install a same plugin, instead of asking them to copy-paste, and maintain, the same lines in their .vimrc
The settings can be saved with the other project files (cvs/svn/git/whatever)
It's really easy to have a configuration file per project -- with the plugin, I have a global configuration file for the coding standards of the overall project, and specific configuration files for each sub-project (which makefile to use, which executable to call, ...)
BTW, sth's solution can be used to source a single configuration file. This is very similar to the plugin approach except the .vimrc has to be parasited with non global options, and it does not support easily multiple/shared configuration files.
This question is old, but it seems like a pretty natural and persistent concern.
My solution is pretty simple. I place a .vimrc file in the root directory of my projects. The first line of the .vimrc file usually sources ~/.vimrc, and then adds the particular configuration I want. I alias tvim='vim -u .vimrc', and use tvim in my personal project directories. "tvim" for "trusted vim," meaning that if I execute it in a directory with a .vimrc file and something goes wrong, I've got no one to blame but myself, since I explicitly said I trusted it. Also, I keep a group of these stored away so that I can sometimes just softlink the one I want for a particular kind of project.
Placing a .vimrc in the working directory actually is supported, only disabled by default. See :h 'exrc' and :h startup for details, setting 'exrc' will enable reading .vimrc from the current directory.
It's also recommended to :set secure when using this. This locks down :autocmd, shell and write commands for .vimrc in the current directory.
Another thing that might be worth looking at is setting up a session (:h session) with a standard view and settings for the project.
All that said, I would probably go with the plugin option detailed by Luc Hermitte myself.
To minimize security risks with ANY "autorun" features for ANYTHING these days, may I advise you to utilize vim's existing features instead of plugins (portability baggage)?
Eg.
My local folder's vimrc file is named "_gvimrc" (on purpose). This reduces the hope for people like phen from amusing himself at our expense. :-)
In my $VIM/.vimrc file, I inserted:
if filereadable("_gvimrc")
source _gvimrc
endif
at the end.
I use "filereadable()" over "fileexists()" as the later has some quirkiness when tortured with opening multiple (10+) files simultaneously, (not sure why).
Of course, you can give your own unique filename to obfuscate potential trouble-makers further. Such as "_mygvimrc", "_gobbledygook", etc. You just need to settle on one standardized name and source it accordingly in your $VIM/.vimrc. Relying on vi/vim internals for this rules out portability issues. BUT, DO NOT name it .vimrc (or _vimrc) to prevent recursive sourcing in case you're editing the $VIM/.vimrc file with vim later.
Been using this since Windoze 98SE, through Windork XP Pro, and now Windorkier 7 (5+ years already). I'll mark a list of .txt files in Explorer and then use "Edit with multiple Vim", resulting in multiple vim windows opening simultaneously. For my work, I do this several times a day, daily. All files got treated with what I set in my local _gvimrc.
Use "editorconfig"
If the kinds of coding standards you would like to enforce are related to indentation style, tab size, file format and charset, then you might want to look into "editorconfig", which is a cross-editor standard to specify this kind of settings in a specific project, and have all editors follow that configuration.
The "editorconfig" specification allows projects to request different settings depending on file extensions or names within the project. (So you can have Makefiles using TABs, your Python scripts using 4 spaces and your shell scripts using 2 spaces for indentation.)
You need a plug-in to use "editorconfig" in Vim. The official website provides one, but personally I'd recommend sgur/vim-editorconfig, which is written in pure Vimscript, so you don't need to worry about external dependencies too much.
Since "editorconfig" aims at cross-editor compatibility, it's quite limited in what it does, so if you want is consistent whitespace, file format (DOS vs. Unix) and encoding (Unicode utf-8, etc.), then "editorconfig" is for you.
Assuming people aren't adding files every few days, you can probably add a modeline at the top of each file. In fact, if your version control system allows it, you could probably enforce a rule that says that each file must have a modeline when it's checked in.
I agree with the plugin approach for security reasons.
There is a very good plugin which has not been mentioned yet. It lets you use a .lvimrc in your project directories.
Try "localvimrc" out:
http://www.vim.org/scripts/script.php?script_id=441
https://github.com/embear/vim-localvimrc
Try vim-localrc
~/
|- .local.vimrc (1)
`- project/
|- .local.vimrc (2)
`- src/
|- .local.vimrc (3)
`- main.c
https://github.com/thinca/vim-localrc/blob/master/doc/localrc.txt
I looked at the plugins that existed and didn't really fancy any of them, so I wrote a simple function that piggy backs on vim-fugitive. The advantage of this is that it knows the root of the project is always the root of the repository, and additionally I can hash the file to keep a trust table. Just put the following in your .vimrc file.
function LoadRepoVimrc()
let l:path = fugitive#repo().tree('.vimrc')
if filereadable(l:path)
let l:sha1 = fugitive#repo().git_chomp('hash-object',l:path)
if !exists('g:SAFE_VIMRC') | let g:SAFE_VIMRC = {} | endif
if has_key(g:SAFE_VIMRC,l:path) && g:SAFE_VIMRC[l:path] ==? l:sha1
execute 'source '.fnameescape(l:path)
elseif confirm("Trust ".l:path."?", "&Yes\n&No",2) == 1
let g:SAFE_VIMRC[l:path] = l:sha1
execute 'source '.fnameescape(l:path)
else
execute 'sandbox source '.fnameescape(l:path)
endif
endif
endfunction
autocmd User FugitiveBoot call LoadRepoVimrc()
set viminfo ^= !
If the ! option is set on the viminfo setting, then the SAFE_VIMRC dictionary will be preserved between runs (note the ^ to prepend the option so it doesn't mess up the n option).