I've written some Vimscript code* in which it's convenient to have a set of shared color names. To use the names, so far I've had to rely on code like this:

execute 'source ' . expand('<sfile>:p:h:h') . '/plugin/colornames.vim'

This means that the scripts have to know something about where the names are defined. Although all of the code is strictly for my own use, I don't like introducing that kind of dependency.

Is there a general way to define Vimscript constants for use by all the (other) plugins?

* colors/custom.vim, status line plugin, tab line plugin.

  • I don't see why you would need to source a file to have access to some variables but you probably want to learn more about the different scopes available in vim reading that: :h internal-variables. And more precisely I think you want to create a global variable so let g:myGlobalVariable = "foo" is probably what you need
    – statox
    Commented May 29, 2020 at 6:57
  • I'm defining the names as global variables. I'll edit the question to clarify.
    – Tony
    Commented May 29, 2020 at 13:45

2 Answers 2


Looks like you need a library plugin that other plugins can depend on.

So far the best way to have library plugins is through autoload plugin files. These files are lazily loaded, they are loaded on demand.

EDIT: IOW, the following will be enough

" library plugin: autoload/colorname.vim
let g:colornames#red = 'rouge'

" client plugin
let red = g:colornames#red
Unfortunately, using a variable named after an autoload plugin won't load the plugin. It only works with functions. This means that at best you can replace runtime plugin/colornames.vim " do you really need to tell where the file is defined? I don't think so with call colornames#let_s_explicitly_load_the_plugin_or_any_other_function_name() Note: We may think that `:runtime plugin/whatever.vim` is less convoluted, yet it has a big disadvantage: it is always loaded. An autoload plugin is loaded only when we need it. It may never get loaded. In the past (before vim7), I was using `macros/` directory to store global scripts that I don't always need.
  • 1
    Im not sure i follow your point about variables: help autoload makes it clear that you can autoload variables.
    – D. Ben Knoble
    Commented May 29, 2020 at 16:44
  • Hum. :/ You're right. I remember having troubles in the past. Is it something that have been patched since the introduction of autoload plugins? Commented May 29, 2020 at 16:57
  • ...vim7.0.0051 I don't know how I've missed it... Commented May 29, 2020 at 17:03
  • thats ok I havent kept up with all the scriptversion stuff :)
    – D. Ben Knoble
    Commented May 29, 2020 at 17:06
  • 1
    Every time I have a doubt, I look at the git blame result on the documentation: github.com/vim/vim/blame/master/runtime/doc/eval.txt :) Or if not possible, sometimes I search in :h version... if I really need the information in my plugins. Commented May 29, 2020 at 17:09

Well, such sort of questions tends to be too vague. But here are a couple of thoughts.

  1. If it's solely "for private use", I could even consider modifying $VIMRUNTIME/rgb.txt. Sure, it feels dirty, but if no one else can see it then why the hell is not?

  2. You can simply use global variables, as it's "for private use" only. Declare them in your vimrc and they will be available in all your scripts. Use compound types to minimize global namespace pollution.

  3. If it already starts feeling like a sort of "a huge functions library" then you will come to using "autoload" feature anyway. You can even add a bunch of "autoloaded" getters/setters and finally implement that (useless in 99% of cases) "encapsulation".

  4. If it's just a shared data and it is probably to be edited, I would think of JSON, as VimScript natively supports it. Sure, that will leave the question where to store and find the data file, but for data files it's absolutely normal to have some sort of "../data" subpath fixed.

  • 1
    Actually, let g:color#red = 123 in ~/.vim/autoload/color.vim will work the same way as autoloaded functions for variables.
    – D. Ben Knoble
    Commented May 29, 2020 at 13:40
  • @Matt: Yep, modifying $VIMRUNTIME/rgb.txt is dirty. It also has to be done manually, and I want to be able to git-pull changes everywhere. I'm using global variables right now. It does look like I can move them to an autoloaded function and call that where I need them, which would at least get rid of any explicit knowledge of file locations. But it'd be nice to have something like a before directory!
    – Tony
    Commented May 29, 2020 at 13:54
  • @D.BenKnoble Yes, but it feels very unsafe to me if simply reading a value of a variable may have so many side-effects.
    – Matt
    Commented May 29, 2020 at 15:27
  • @Tony vimrc is sourced before all plugins. Hence there's no need to have some extra "before" subdirectory.
    – Matt
    Commented May 29, 2020 at 15:30
  • @Matt, there is a big caveat, expecting the .vimrc to contain some specific lines only work with private/personal plugins that are not meant to be distributed. Commented May 29, 2020 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.