I work in several groups, each of which has its own tab/indentation/spacing standards in C.
Is there a way to have separate selectable VIM configurations for each so, when I edit a file, either:
I do something like set group=1 to select a configuration
a local .vimrc that lives in the working directory is used to set the configuration automatically
I have this in $HOME/.vimrc:
if filereadable(".vim.custom")
so .vim.custom
endif
This allows me to put a .vim.custom file in every directory to load commands and options specific to that directory. If you're working on multiple projects that have deep directory structures you might need something more sophisticated (e.g. walk up the directory tree until a .vim.custom is found), but the same basic idea will work.
UPDATE:
I now do something like this in order to read a .vim file from the same directory as the file I'm editing, regardless of what the current directory is.
let b:thisdir=expand("%:p:h")
let b:vim=b:thisdir."/.vim"
if (filereadable(b:vim))
execute "source ".b:vim
endif
In Summary
There are a few ways to do this, of which most have been suggested, but I thought I'd summarise them with two extra ones:
Per-directory vimrc - has the disadvantage that Vim must be started in the right directory: if your project is in ~/project1 and you have ~/project1/.vim.custom and do cd ~ ; vim project1/file.c, the custom settings won't be found.
Modelines - very effective, but has the disadvantage of needing to add them to all files (and remember to add them to new files)
Directory specific autocommands - this is very effective
Scan for a specific header in the file (see below) - this is the one I've used most in the past where working for different companies or on clearly named projects
Per-directory vimrc that's checked when the file is opened (see below). Another fairly easy one to implement, especially if your project code is all in one place.
Scanning for a Header
In a lot of organisations, there's a standard header (with a copyright notice and project name etc) at the top of every source file. If this is the case, you can get Vim to automatically scan the first (e.g.) 10 lines of the file looking for a keyword. If it finds it, it can change your settings. I've modified this to make it simpler than the form I use (which does lots of other things), but create a ~/.vim/after/filetype.vim (if you don't have one yet) and add something like this:
au FileType * call <SID>ConfigureFiletypes(expand("<amatch>"))
" List of file types to customise
let s:GROUPNAMETypes = ['c', 'cpp', 'vhdl', 'c.doxygen']
func! <SID>CheckForGROUPNAMECode()
" Check if any of the first ten lines contain "GROUPNAME".
" Read the first ten lines into a variable
let header = getline(1)
for i in range(2, 10)
let header = header . getline(i)
endfor
if header =~ '\<GROUPNAME\>'
" Change the status line to make it clear which
" group we're using
setlocal statusline=%<%f\ (GROUPNAME)\ %h%m%r%=%-14.(%l,%c%V%)\ %P
" Do other customisation here
setlocal et
" etc
endif
endfunc
func! <SID>ConfigureFiletypes(filetype)
if index(s:GROUPNAMETypes, a:filetype) != -1
call <SID>CheckForGROUPNAMECode()
endif
endfunc
Whenever a file of any type is opened and the file type is set (the au FileType * line), the ConfigureFiletypes function is called. This checks whether the file type is in the list of file types associated with the current group (GROUPNAME), in this case 'c', 'cpp', 'vhdl' or 'c.doxygen'. If it is, it calls CheckForGROUPNAMECode(), which reads the first 10 lines of the file and if they contain GROUPNAME, it does some customisation. As well as setting expandtabs or whatever, this also changes the status bar to show the group name clearly so you know it's worked at a glance.
Checking for Configuration When Opening
Much like JS Bangs' suggestion, having a custom configuration file can be useful. However, instead of loading it in vimrc, consider something like this, which will check when a .c file is opened for a .vim.custom in the same directory as the .c file.
au BufNewFile,BufRead *.c call CheckForCustomConfiguration()
function! CheckForCustomConfiguration()
" Check for .vim.custom in the directory containing the newly opened file
let custom_config_file = expand('%:p:h') . '/.vim.custom'
if filereadable(custom_config_file)
exe 'source' custom_config_file
endif
endfunction
You can also put autocommands in your .vimrc which set specific options on a per-path basis.
au BufRead,BufNewFile /path/to/project1/* setl sw=4 et
au BufRead,BufNewFile /path/to/project2/* setl sw=3 noet
Plugin doing the right thing:
http://www.vim.org/scripts/script.php?script_id=441
“This plugin searches for local vimrc files in the filesystem tree of the currently opened file. By default it searches for all ".lvimrc" files from the file's directory up to the root directory and loads them in reverse order. The filename and amount of loaded files is customizable through global variables.”
Assuming your fellow developers won't complain about it, you can always add vim settings to each file in the comments.
/*
* vim:ts=4:sw=4:expandtab:...
*/
int main(int argc, char **argv)
{
...
I created an open-sourced tool for just this purpose. Forget the headers, scanning, configurations, and local vimrc files.
Try swim.
Swim
swim is a quick tool for switching vimrc files and creating convenient aliases. Here's a short usage list. See the Github repo for a walkthrough gif and download instructions:
Usage
swim add ~/dotfiles/myVimrc favorite #Add new swim alias
swim ls #Show available swim aliases
swim add https://raw.githubusercontent.com/dawsonbotsford/swim/master/exampleVimrcs/vimrcWikia.vim example
swim with favorite #Set alias favorite as primary .vimrc
swim with main #Set alias main as primary .vimrc
Read More
https://github.com/dawsonbotsford/swim
After trying out the localvimrc plugin suggested by the previous poster, I very much like having non-futzy per-project control over vim settings.
It does ask confirmation before loading a .lvimrc file by default but there is a setting to automatically load .lvimrc files. Some might see this as a security hole, but it works as advertised.
I chose to .gitignore the .lvimrc files. Alternatively you can check them in as a form of shared settings (tab/space expansion, tabstops, other project-specific settings).
As mentioned by sledge the usage of that plug-in is the best option I have seen and use. jerseyboy commented that the utility recommended ask for confirmation before loading (ie. after opening every file). To avoid this just set at your main .vimrc the list of local .lvimrc files:
let g:localvimrc_whitelist='/development/kernel/.lvimrc'
Here's a variation on jamessan's
function! ConditionalLoad()
let cwd = getcwd()
if getcwd() =~ $HOME . "/src/mobile"
so $HOME/.vim.mobile
endif
endfunction
autocmd VimEnter * call ConditionalLoad()
I will frequently launch vi without a specific file that I'm jumping to so this enables loading config conditionally based on the current working directory. Downside is that the config isn't applied based on file but off of working directory.
I work in several groups, each of which has its own tab/indentation/spacing standards in C.
I work with all sorts of open source, all at the same time. It's not practical to be creating separate .vimrc files and reconfiguring the formatting standards. More than a decade ago, I finally got tired of dealing with the editor configuration and wrote a program called autotab to handle it.
When autotab is set up with Vim suggested, each time you load a file into Vim, autotab is invoked on it, and the Vim settings output autotab are passed to a :set command.
autotab reads several thousand lines from the file, analyzes them and determines the settings for the expandtab, tabstop and shiftwidth parameters.
It figures out whether the file uses hard tabs or just spaces for indentation, and it figures out the indentation size. If the file is indented with tabs, it figures out the right tab size, based on rendering the file sample using various tab sizes and judging it according to heuristics like line-over-line alignment of internal elements.
It works well enough that I stopped tweaking the algorithm years ago. If it gets confused, it's almost always because the file has formatting issues, such as the use of multiple conventions at the same time.
It is also "agnostic" of the file type and works well with a variety of different languages. I use it not only over C, but shell scripts, Lisp, Makefiles, HTML, and what have you.
Note that it doesn't handle other parameters of formatting that may be project-specific, like for instance, in C files, whether case labels in a switch statement are indented or not, or whether wrapped function argument lists are simply indented, or aligned to the opening parenthesis of the argument list. Vim does have settings for that sort of thing, and so the program could be plausibly extended to analyze the style and output those parameters.
Looking for mostly the same issue I also found the Sauce plug-in: http://www.vim.org/scripts/script.php?script_id=3992
It claims:
Sauce is a lightweight manager for multiple vimrc files, which can be used to load different settings for different environments. In short, you can maintain lots of different vim settings files and only load the one(s) you need when you need them.
I find it particularly interesting that it keeps it configuration all in its data directory instead of expecting the user to sprinkle dotfiles across the filesystem. This though often rather a metter of personal taste.
I have yet to test it though.
You can use stow for switching configuration (any dotfiles, not only .vimrc)
Install stow:
$ apt install stow
Create multiple directories for each configurations:
~$ ls -d ~/dotfiles/vim*
vim-all vim-webdev vim-go
Put different .vimrc's in them:
$ find ~/dotfiles -name .vimrc
/home/username/vim-golang/.vimrc
/home/username/vim-webdev/.vimrc
/home/username/vim-all/.vimrc
Now you can instantinate vim-golang config with this command (should be run inside dotfiles directory):
~$ cd ~/dotfiles
dotfiles$ stow -v vim-golang
LINK: .vimrc => dotfiles/vim-golang/.vimrc
Now it's linked:
$ cd ~ && ls -l .vimrc
.vimrc -> dotfiles/vim-golang/.vimrc
If you need to switch config, just re-stow it:
~$ cd dotfiles
dotfiles$ stow -v -D vim-golang
UNLINK: .vimrc
dotfiles$ stow -v vim-webdev
LINK: .vimrc => dotfiles/vim-webdev/.vimrc
$ cd ~ && ls -l .vimrc
.vimrc -> dotfiles/vim-webdev/.vimrc
More reading of it here: Managing dotfiles with GNU stow
Pros: pretty simple, no vim plugin dependencies, can be used for managing all dotfiles, not only .vimrc.
Cons: configs are independent of each other, you need to manage/update each of them separately (if you dont switch/update you configs too often - it'll not be the issue).
Related
A long file paths is broken up over multiple lines in the Vim quickfix window which then for example does not allow to jump to the error location displayed in the qf.
The file (and the lines around) are diplayed in the quickfix window as (the example is the output from neomakes pdflatex)
|| Enter file name:
|| /long/path/to/file/.../loca
tionOfTexFiles/myTexFile.tex|144 error| Emergency stop.
|| read
to be able to follow to the file line by lnext/cnext I should have
/long/path/to/file/.../locationOfTexFiles/myTexFile.tex|144 error| Emergency stop.
For quickfix files I have the following relevant (in my view) settings which are set to:
setlocal nolinebreak
setlocal nowrap
setlocal textwidth=9999
So I am wondering how I can display the file path in one line within the quickfix window?
On :make, Vim invokes 'makeprg', captures the output, and then parses it according to 'errorformat'. The latter does support multi-line error messages (cp. :help errorformat-multi-line), but that is mostly for what I would call intentional linebreaks, as specified by the compiler. What you suffer from is unintentional linebreaks because of line wrapping (due to overly long paths).
Now, I don't know about "neomakes pdflatex", but it looks like that tool creates the linebreaks, whereas it shouldn't, as Vim is capturing the output, and there's no receiving terminal (or user). Investigating in that direction (or opening an issue at the project's tracker) might be helpful.
The mentioned Vim options ('linebreak', 'wrap', etc.) have nothing to do with it. They apply to normal buffers; the quickfix buffer as such is not modifiable.
Workarounds
A possible workaround might be to :cd first to a directory that is "closer" to the processed files (or even :set autochdir); this might avoid the long paths in the output.
Alternatively, you may "unmangle" the output by adding a sed stage after the compiler:
let &makeprg .= "| sed -e 's/.../...'"
If I'm not mistaken, the issue is on pdflatex side. The || mark is a good indication: you'll have one per output line -- in case filename and/or lines numbers are recognized, they'll be fed in between the bars.
So. This means you'll need a way to fix the path names. It'll be better to do it outside vim. I'm not saying this is trivial. I'm just saying that if you can have a program able to fix pdflatex outputs, you'll just be one pipe away from the solution (plus a correct forwarding of error codes...).
If you prefer to implement it in vim script, this is possible. But you'll experience side-effects. In my BuildToolsWrapper plugin I'm able to post-process compilation output in vim side, but the result is far from being perfect. I'm working on getqflist() result, and parse each line. When I found a line where I want to fix the filename, it's not simply about fixing the filename but also about assigning a valid buffer number to it. See this function where I can replace a filename with another one. The magic happens where lh#buffer#get_nr() is used. Still you'd need to implement a vim script able to merge split filenames.
IOW: my understanding is that vim is not involved. It could be used to fix the issue, but IMO this is not the easier path to undertake.
I work on a growing project with vim. I like to have most of the project files open in the same session. However, as the project's growing, I start to have too many files open at the same time; switching between files [*] starts getting a bit unproductive at 40+ files because the list gets too long (for, say, 20 files this way of navigating works very well for me, however).
Is there a way to split the session in multiple "sub-sessions" in the same instance of vim?
How I imagine it is that each session would contain, say, 20 files and only list those with :ls, and that I could switch between them in the same vim window (basicallly the same as if I'd run multiple instances of vim in the same shell and switch between them with Ctrl-Z; fg %X, just without leaving vim).
[*] I like to navigate between files with :ls followed by :bX (or directly :bX in case I've memorized a buffer number), along with :bp/:bn, and I always have at least two split open, and this workflow works quite well for me, so I'm not looking for more efficient alternatives to :ls.
I never use :ls. However I often work on big projects, and I open (many) files from different projects (and I'm still able to compile what I want in the mode I want (debug, release, ...), generate tags independently for each project, have different coding styles, etc)
Your question seems to be about "How do I go from one file to another". I have many split windows opened simultaneously and I jump from one to the other with:
:sb, which supports tab completion on filenames (already opened in buffer)
:sp **/filename*<tab> (When it's not already opened)
an old plugin of mine -- others usually use Unite, command-T or other similar plugins -- to merge :sp and :sb into one command.
Tags. The default integration of tags (/csope) is already nice. Yet, I've developed lh-tags, in order to simply the tags navigation in a world of overloaded and overridden functions as it's the case in C++.
EDIT: I've just pushed a highly experimental :Project <name> :ls feature in lh-vim-lib. Note: this new project feature wasn't meant to do what you're looking for, but it's easy to have a restricted :ls thanks to it.
To use it, you'll have to first register buffers to one project or another. Here, I recommend plugins like local_vimrc if each project can be distinguished as files under a given directory. For each root directory place a _vimrc_local.vim file in it that'll contain:
:let s:k_version = 1
" Global definitions executed everytime we enter a file belonging to the project
" This is where we set g:lobal_variables and options for project-unaware plugins.
....
" Then the anti-reinclusion guards for buffer definitions
if &cp || (exists("b:loaded__my_foobar_project_settings")
\ && (b:loaded__my_foobar_project_settings > s:k_version)
\ && !exists('g:force_reload__my_foobar_project_settings'))
finish
endif
let b:loaded__my_foobar_project_settings = s:k_version
let s:cpo_save=&cpo
set cpo&vim
" HERE, we say the current buffer belongs to a project
" solution 1 when we need more control
:call lh#project#define(s:, {'name': 'YouProjectName'})
" OR solution 2 which is easier to manipulate (tab completion, ...)
:Project --define YourProjectName
You can also have a smaller granularity if you wish (this is something which is still poorly documented).
Then, you'll be able to consult the list of projects with :Project --list, or to consult the buffers associated to a given project with :Project YouProjectName :ls.
I just switched from Sublime Text to GVIM (on Windows). I am still debating whether I should continue ST or move completely to VIM. One feature that I desperately need (or miss) are
Ctrl+P to go to any file that I want in my list of folders.
Ctrl+Shift+f to find (and replace) any text in those list of folders.
I had added number of folders using Add Folders to Project feature in Sublime Text 3. It was really helpful. Now, I know that CtrlP plugin for VIM can do similar thing, but I can't figure out how to make it search the folders that I want, and not the root directory of current file.
I played around a bit with setting path in my vimrc file without much success.
Can you please help. If it is a repeated question, please excuse me.
Thanks.
AFAIK, ctrlp plugin only searches within one directory (and its descendants). Use the Unix features: make a directory with links to out-of-project directories you are interested in. This way, the association with out-of-project directories is not just something the editor knows about, but something recorded in the actual project.
Search and replace is a bit stickier thing. You want to work with all the files you are interested in, then repeat the replace command through all of them. For example, if you want to do the search for foo and replace with bar on all C files here and under,
:args **/*.c
:argdo %s/foo/bar/g
Ctrl+P to go to any file that I want in my list of folders.
The :find command can be used to "find" a file in the directories specified in the 'path' option:
set path+=/some/arbitrary/path
set path+=/another/one
:find *foo
I find these two mappings very handy:
nnoremap <key> :find * " search in every directory
" in 'path'
nnoremap <key> :find <C-R>=expand('%:p:h').'/**/*'<CR> " start from the directory
" of the current file
Ctrl+Shift+f to find (and replace) any text in those list of folders.
What amadan said above.
Good switch! So you’ve discovered CtrlP. It has extensive documentation built in. Use :h ctrlp to see the full vimdocs explaining the various options. It’ll explain some important settings for working dirs, which are pretty important for a good experience with it. Take for example some of the settings I use:
" The one you really care about...
" Set root to CWD. Another good option is 'r' for VCS mode.
" You should start vim in the root of your project tree
let g:ctrlp_working_path_mode = 0
" You _can_ switch dirs
let g:ctrlp_extensions = ['dir']
" Avoid big/unimportant project areas
set wildignore+=*/node_modules/*,*/build/*,*/components/*,*/_public/*,*/tmp/*,*/vendor/*
" Cache -- get used to pressing F5 on tree changes/additions
let g:ctrlp_use_caching = 1
let g:ctrlp_clear_cache_on_exit = 0
" Somewhat self-explanatory
let g:ctrlp_show_hidden = 1
let g:ctrlp_switch_buffer = 2
let g:ctrlp_max_depth = 6
let g:ctrlp_max_height = 50
" Open *h*orizontally and *j*ump to first win.
let g:ctrlp_open_multiple_files = 'hj'
" Use <C-d> to toggle
"let g:ctrlp_by_filename = 1
For further control of where to look for files outside your working tree, consult g:ctrlp_user_command. There is a Windows example using dir. You’d use that, but with your desired extra paths.
You might also want to add NerdTree, a nice complement to CtrlP. It is reminiscent of ST’s sidebar. Use its ? to get help. It has a menu that lets you quickly add files and dirs, maybe like you’re wanting out of “Add folders to project”.
For search-and-replace, look at ag.vim. I map it to <leader>g (meaning “grep”).
Those mentioned are some of my favorites, but you should explore the world of Vim plugins to decide which others are worth adopting. I recommend trying one at a time while you’re new, rather than a sometimes-opaque “distribution”. Tools to make plugin management easier are Vundle / Pathogen (choose one).
Eureka...!!!!!
After searching tirelessly for days (and sleepless nights), I found my answer (please read on).
First some foolosophy though
I was so keen not to give up on Vim. But this issue was just eating me from inside, and was disruptive in my work flow. I have many project folders in windows that I want vim to search through. Ctrl+p for some reason never really worked. I had some not-so-nice thoughts of giving up on Vim. and then I found this!
My Answer
This is a little different from what I expected. But the answer is Everything (by VoidTools). It allows to search from anywhere and gives results in a fraction of sec. It is by far the best filename search tool in Windows. It supports Regex. (though it is not text search tool). It has a command line interface called
es.exe
using Vim's FindEverything.vim plugin (FindEverything), I was able to search not only through my project folders, but pretty much anywhere. It returns the results in the vim buffer.
Thanks Y'all for your help. I know that not everyone may agree with this solution. But on Windows, this is by far the best solution, I found! Hopefully, it is useful for others why are in same boat!!!
I have this line in my .vimrc file:
set directory=~/.vim/swapfiles//
(Note that one extra slash makes the directory names to be included instead of just file names to reduce conflict)
The above config works fine on my Linux machine, but the problem is when I use the same file on Windows I get some warning about the file cannot be read. That's probably because vim is looking for ~/.vim/swapfiles/ directory, which Windows unfortunately don't have.
Is there any way to store my swap files on Windows somewhere (better if it could be in C:\Program Files\Vim\vimfiles\)?
CASE #2
If you got answer for my above question, here is the another one. I also have some lines similar to this:
autocmd filetype python source ~/path/to/file/python.vim
Windows confuses at this point too. How can I patch up?
If you don't want to introduce a $MYVIM variable as ZyX suggests, maybe an alternative is placing the runtime files in $HOME/.vim instead of the default $HOME/vimfiles on Windows. You can then use ~/.vim/... everywhere. This also helps with synchronizing the files across multiple mixed-platform machines.
" On Windows, also use '.vim' instead of 'vimfiles'; this makes synchronization
" across (heterogeneous) systems easier.
if has('win32') || has('win64')
set runtimepath=$HOME/.vim,$VIM/vimfiles,$VIMRUNTIME,$VIM/vimfiles/after,$HOME/.vim/after
endif
Maybe what you want is to have directory set based on the entries in runtimepath? Try this:
let &directory = substitute(&rtp, ",", "/swapfiles//,", "g")
With the default runtimepath setting on Unix-y systems you get
$HOME/.vim/swapfiles//,
$VIM/vimfiles/swapfiles//,
$VIMRUNTIME/swapfiles//,
$VIM/vimruntime/after/swapfiles//,
$HOME/.vim/after//
and on Windows
$HOME/vimfiles/swapfiles//,
$VIM/vimfiles/swapfiles//,
$VIMRUNTIME/swapfiles//,
$VIM/vimfiles/after/swapfiles//,
$HOME/vimfiles/after/swapfiles//
I agree, the after directories are unwanted, but vim will pick the first directory that exists and allows file creation so if you don't create the swapfiles sub-directory they won't be touched.
You might want to consider prepending these to the default value instead of replacing it so the defaults are available as a fallback if none of the directories exist.
I don't understand why you have the auto commands you mention. The default settings of runtimepath with filetype plugin on should take care of that for you.
Of course you always have the option of explicitly checking the platform and using different settings as in
if has("win32")
" settings for windows
elif has("win32unix")
" settings for cygwin
elif has("unix")
" settings for unix
elif has("macunix")
" settings for macosx
endif
If you want to avoid an error if a file does not exist then you can use the following definitions in your vimrc
func! Source(file)
if filereadable(a:file)
exec "source " . fnameescape(a:file)
endif
endfunction
com! -nargs=1 -complete=file Source call Source(<f-args>)
and change source to Source when the file might not exist.
First of all, vim translates all forward slashes to backward on windows thus it won’t hurt having slashes. Just in case you think it can be a source of trouble.
Second, it is not impossible to have ~/.vim and all other directories on windows, just some programs don’t want to work with names that start with a dot. You may just add this to runtimepath as it is not there by default on windows and move all user configuration there.
Third, in most places you have a filename you may use $ENV_VAR. It includes setting &rtp, &directory and using :source. So the solution may be the following:
if has('win16') || has('win95') || has('win32') || has('win64')
let $MYVIM=$HOME.'/vimfiles'
else
let $MYVIM=$HOME.'/.vim'
endif
set directory=$MYVIM/swapfiles
autocmd FileType python :source $MYVIM/after/ftplugin/python.vim
(though I agree with #Geoff Reedy that there should be no need in using the last line).
And last, modifying and storing something in C:\Program Files is not the best idea, neither for you nor for the program itself (by the way, vim won’t modify or store something there unless you told it to). It is to be modified by installation, update and uninstallation processes, not by anything else.
I fully agree with Geoff Reedy that the autocmd shouldn't be necessary. In other cases, you can use :runtime instead of :source. It will automatically search all (user and system directories in 'runtimepath'.
I use etags with vim on linux for source(*.c, *.h) code browsing. I have created a TAGS file bu giving command :
etags --members *.c *.h
TAGS file gets created but when I start browsing say one of the source files named 1.c which has a C structure variable defined and used in one of its function definitions(The structure name is a typedef in some other 1.h file). I open the file 1.c in vim and then I do CTRL - ] by placing cursor on that struct type, etags does not browse to the header file 1.h which has declaration of this structure.
This only happens when i have below line in my .vimrc, when i comment below two lines, etags based source browsing works fine.
set TAGS=./TAGS;$HOME
set tags=./tags;$HOME
I am trying to tell vim where to locate the TAGS file. starting from current folder till my home dir. What is incorrect here?
What is the correct syntax for above command?
Also does ctags/etags browsing with vim, show from where all a given function is called from?
If yes, what is the command to see that?
Locating tags file
Vim's settings are case-sensitive so set TAGS= is invalid. You must use set tags= in lowercase.
Vim will stop at the first match so you can't really expect it to search for a tag in tags and TAGS. These files can be searched in turn with:
set tags=./tags,./TAGS;$HOME " 1. tags, 2. TAGS, 3.… until $HOME
Also, search is not performed by etags, it's done by Vim itself.
Jumping to function calls
No, ctags and etags only index declarations. To jump to usage you'll need cscope