Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vim version dependencies #54

Closed
steeef opened this issue Aug 11, 2014 · 3 comments
Closed

Vim version dependencies #54

steeef opened this issue Aug 11, 2014 · 3 comments
Labels

Comments

@steeef
Copy link

steeef commented Aug 11, 2014

I've looked through the README and recent issues, but I haven't seen a solution for this.

I've got a number of plugins specified in the following manner:

 if v:version > 703 || (v:version == 703 && has('patch584'))
    Plug 'Valloric/YouCompleteMe', { 'do': './install.sh' }
endif

Kind of messy to put it in my list of plugins.

There are already conditions for filetypes and on specific commands. What about on a function return? Say if a specific function returns 0 (equivalent to "false" in vimscript, right?), don't load the function .

@vheon
Copy link
Contributor

vheon commented Aug 11, 2014

So what are you proposing? What would you write in your vimrc?

@junegunn
Copy link
Owner

Something like this?

Plug 'Valloric/YouCompleteMe', { 'do': './install.sh', 'if': v:version > 703 }

If that's what you're proposing, I'd given thought about providing such syntactic sugar, but decided not to do it, because:

  1. It has some gotchas. You can't use s: variables and functions inline, which makes you unnecessarily expose functions and variables as globals (g:). (And I should mention this limitation in the documentation.)
  2. And I don't think using native if statement is messy. I also use several conditional statements (https://github.com/junegunn/dotfiles/blob/master/vimrc#L50-L52). If there are several plugins that share a condition it's more concise to group those in an if-clause than to repeat the same if option.

So I concluded it wasn't really worth it especially since I prefer to keep the set of options as small as possible. But I'm still open to suggestions. Let me know if you have different ideas.

@steeef
Copy link
Author

steeef commented Aug 12, 2014

Thanks for the explanation. I think that makes sense, especially your examples, @junegunn. Consider it closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants