Using Vim version: 7.4
In this line of the Python-mode documentation: https://github.com/python-mode/python-mode/blob/01c3131343aaa3c76f8cb656b5e9f54ac90ca04b/doc/pymode.txt#L234
it says that I can turn-on the variable (g:pymode_run) using
let g:pymode_run=1,
to run my python file using “:PymodeRun” or use it via ‘<leader>r’
If there is no modification to my Vimrc file, the default setting is:
let g:pymode_run=1
However, if the default setting in your vimrc file is
let g:pymode_run=0,
you load your .vimrc, and attempt to then change the variable using
let pymode_run=1 or let g:pymode_run=1 (both of this is equivalent, as we are dealing with the global variable here),
:PymodeRun doesn’t work.
If you do “:so ~/.vimrc” after changing let g:pymode_run=1, it doesn’t work either.
The only solution to this, that I found, is to change to “let g:pymode_run=1” in your ~/.vimrc, shutdown VIM and restart vim.
Then it works as expected.
Since pymode_run is a variable which determines whether :PymodeRun should run or not, shouldn’t changing the variable pymode_run from 0 to 1 in the current VIM session, also enable running :PymodeRun, withough having to reload VIM?
g:pymode_run seems to be used here, which means that the variable is used to decide if the command :PymodeRun (and related bindings) should be defined or not in the first place. In other words, it isn't checked when calling :PymodeRun, but is checked on editing python files. This is why setting the value afterwards doesn't work. This is probably because changing the option while editing is not expected (I don't see much rationale either).
As this variable is checked in ftplugin, I believe reloading the file (:ed %) suffices for let g:pymode_run=1 to take effect.
I'm using the vimtex plugin with vim-plug plugin manager to edit LaTex files. I'm trying to disable the Callback feature in my vimrc (so I stop getting warnings about it whenever I open a .tex file), so I let g:vimtex_compiler_latexmk.callback = 0, but I get an error saying g:vimtex_compiler_latexmk is an undefined variable.
Attempting :echo g:vimtex_compiler_latexmk gives the same error message.
The only variable I can seem to change or even view is g:vimtex_enabled, so if I want to let g:vimtex_enabled = 0, I can do that and disable vimtex altogether.
Any ideas why and what I can do to fix this? Vimtex otherwise works flawlessly despite this.
I'm running VIM 7.4 on Linux Mint 18.
Vim doesn't let you initialize a dictionary variable like that. There's no default value for g:vimtex_compiler_latexmk, so you first have to initialize it as a dictionary:
let g:vimtex_compiler_latexmk = {}
let g:vimtex_compiler_latexmk.callback = 0
Or just initialize and assign at once:
let g:vimtex_compiler_latexmk = {'callback': 0}
Either way, once it's initialized, you can use the . accessor shortcut.
The reason you're only seeing g:vimtex_enabled is because vimtex autoloads when you access a .tex file. Load one up, and you'll see a lot more variables. You still won't see g:vimtex_compiler_latexmk, though, because it has no value unless you set one.
I suspect you are assigning g:vimtex_enabled in your vimrc, and that's why you see that one even without loading a LaTeX file.
just found out, that vim runs all ftplugins that starts with the same name.
For example:
Detected filetype = ocr
These files have different versions.
Therefore I have different ftplugins:
ocr => Base (Checks the file-version and sets the correct filetype)
ocr_01 => Version 01
...
ocr_n => Version n
When opening an ocr-File, the filetype is detected as 'ocr' -> the ocr-Base-ftplugin will load.
It checks, which version the file has (e.g. 01) => the filetype will be set to ocr_01.
I expect, that only the filetype-plugin ocr_01 loads, but all ftplugins starting with 'ocr' are: ocr_01, ocr_02....
How to disable this?
The underscore has a special meaning in filetype plugin names; it allows to have additional scripts for a filetype. See :help ftplugin-name for the details.
You can just use a different separator or remove it entirely. However, please reconsider your approach, because what you're attempting to do is unconventional. (I haven't seen that used in the wild so far, and Vim already supports almost 200 filetypes out of the box.)
It may be a bad idea to have different filetypes, because usually (I don't know about your particular one), even different versions of a file format have much more in common than what the differences are. By choosing distinct filetype names, users will have to duplicate their settings (and any related syntax customizations) for each version. Instead, consider what the default sh filetype does: It handles various shells (POSIX, Korn, Bash, ...) with a single script (and syntax), and enables specific behavior via buffer-local variables (e.g. b:is_bash) and conditionals on them.
I've recently started using racket, and one of the first things I've done has been to try and get the vim TagList plugin to work with it. However, it doesn't work in the slightest. I can open racket files and the TagList window will be as blank as if I had opened a text file.
According to the extending page* I have added the following to my ~/.vimrc file:
let Tlist_Ctags_Cmd = 'ctags --langdef=racket --langmap=racket:.rkt --regex-racket=/^\(def[a-zA-Z0-9\-_\?\/\\]+[ \t]+([a-zA-Z0-9\-_\/\\\?]+)/\1/d,definition/'
let Tlist_racket_settings = 'racket;d:Definition'
The extra ctags stuff is also in my ~/.ctags file, but TList was spitting out errors about my setting line not being any good. I did original try to use ctags existing scheme functionality, but I had the same nothing results. To use the existing scheme functionality, i tried the following in my ~/.vimrc
let Tlist_Ctags_Cmd = 'ctags --langmap=scheme:.rkt'
let Tlist_racket_settings = 'racket;f:Functions'
If anyone else has any ideas on how to get it working, then I would be extremely grateful.
Thanks,
I'd post a link to the ctags one page as well, but it wont let me (new user). A link to it can be found on the extending taglist page.
EDIT
ctags from the command line
I can use ctags from the command line. Testing with the ctags line on the TagList FAQ page I get the following:
$ cat ~/.ctags
--langdef=racket
--langmap=racket:.rkt
--regex-racket=/^\(def[a-zA-Z0-9\-_\?\/\\]+[ \t]+([a-zA-Z0-9\-_\/\\\?]+)/\1/d,definition/
--regex-racket=/^\(define\-syntax(\-rule)?[ \t]+([a-zA-Z0-9\-_\/\\\?]+)/\2/m,macro/
--regex-racket=/^\(define?[ \t]+(([a-zA-Z0-9\-_\/\\\?]+)[ \t]+\(lambda|\(([a-zA-Z0-9\-_\/\\\?]+))/\2\3/f,function/
$ ctags -f - --format=2 --excmd=pattern --fields=nks XMMSClient.rkt
defenum XMMSClient.rkt /^(define-syntax defenum$/;" m line:11
defxmmsc XMMSClient.rkt /^(define-syntax defxmmsc$/;" m line:20
libxmmsclient XMMSClient.rkt /^(define libxmmsclient (ffi-lib "libxmmsclient"))$/;" d line:5
Output is the same if I force the language definition with switches, or if I change the language to scheme.
About TagBar
I had not seen TagBar before people had suggested it. Interestingly enough, it just worked with the changes to my .ctags file. Unfortunately, I've not found a setting for showing the tags from all loaded buffers the way TagList does, so I would prefer to use TagList.
I'd post comparison images, but I don't think its going to let me, as a new member. As per romainl's suggestion, I can set the vim filetype to scheme, and it does work. This however only seems like an 80% solution, when the documentation according to the extending pages seems to suggest that what I have should work. Perhaps I should be looking at filing a bug report.
Thanks again,
Here is a small racket snippet I lifted from the official documentation and saved as tt.rkt:
(define (checker p1 p2)
(let ([p12 (hc-append p1 p2)]
[p21 (hc-append p2 p1)])
(vc-append p12 p21)))
Without racket-specific syntax/indent files nothing is shown whether ft is set to racket (of course) or nothing (the default). If I :set ft=scheme, both TagList and TagBar list checker as "function".
From left to right: the file, TagBar, TagList.
From what I understand, "Racket" is a rebranding of some Scheme derivative. If it doesn't deviate too much from the norm, adding this line in your ~/.vimrc may help:
autocmd BufRead,BufNewFile *.rkt set filetype=scheme
I've been struggling with the same issue, though for xslt files... My solution was found by poking around in taglist.vim, whereby I added a line for
let s:tlist_def_xslt_settings = 'xslt;f:function:v:variable'
try doing a search for the s:tlist_def_ parts of the Vim code and put in something which looks sensible. There's a similar mechanism within Tagbar. I've not read the code through in detail, so I don't know why it would need this and not use the output from cta
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).