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

whitelist plugins #122

Open
jmatraszek opened this issue May 17, 2014 · 9 comments
Open

whitelist plugins #122

jmatraszek opened this issue May 17, 2014 · 9 comments

Comments

@jmatraszek
Copy link

Is it possible to load only whitelisted plugins?

@tpope
Copy link
Owner

tpope commented May 17, 2014

Not yet. It's a little unclear how that would interact with built-in plugins.

@FrostyX
Copy link

FrostyX commented Jul 7, 2014

I would prefer function for loading specific plugin rather than whitelist (or both).

I think it would be great to have possibilty to do:

call pathogen#load('nerdtree')
call pathogen#load('YouCompleteMe')
call pathogen#load('vim-fugitive')
...

Instead of call pathogen#infect(). I mean, infect() is awesome, but few plugins has dependency on some system package so you could do conditional load, e. g.

if executable('ctags')
    call pathogen#load('taglist.vim')
endif

Ok, we can negate the condition and instead of load we can do call add(g:pathogen_disabled, 'taglist.vim'), but it's a bit hacky and I think we can't do try-catch for specific plugins.

Unfortunately I can't code this feature and send pull request, so I hope my opinion was constructive and will help to someone who will.

FrostyX

@tpope
Copy link
Owner

tpope commented Jul 7, 2014

So fugitive, for example, will work just fine without Git, up till the point you explicitly invoke a command. I think plugins that don't are broken, generally speaking. My strategy for dealing with these "broken" plugins is to install them ad hoc on a per machine basis, and limit my shared config to safe plugins.

That said, I think the approach I assume you want (put everything you could conceivably want in submodules and then conditionally load them) is valid. I'm just not sure it's a great fit for pathogen. I think if I ever decided to pursue it, it would be in a different plugin entirely.

@FrostyX
Copy link

FrostyX commented Jul 7, 2014

will work just fine without Git, up till the point you explicitly invoke a command. I think plugins that don't are broken

I totally agree with this, so I will open new issues in that plugins trackers

I think the approach I assume you want (put everything you could conceivably want in submodules and then conditionally load them) is valid. I'm just not sure it's a great fit for pathogen.

Why not? I know there is a Vundle which is doing it this way, so those who wish this feature could use it, but why? I think that pathogen#infect() must go through every bundle and do exactly that, what requested pathogen#load(...) function would do. So tecnically we are talking about a little refactoring and adding some boolean g:pathogen_lazy_import variable.

Or did you meant it in a way, that is a philosophical problem?

@tpope
Copy link
Owner

tpope commented Jul 7, 2014

Since Pathogen doesn't handle installation, this would force the user to both install by hand and update their vimrc on install, and do the reverse on uninstall. That's a ridiculous amount of effort plus opens up 4 different edge cases if they forget a step.

@FrostyX
Copy link

FrostyX commented Jul 7, 2014

That's right, pathogen is awesomely easy to use - just one command and new bundle is installed and prepared to use. My suggestion (actually simplier now) is to keep all of this right as it is, cause it's great, and just add one function pathogen#load(...) to load specified bundle by its name.

Most of pathogen users will keep call pathogen#infect() in their .vimrc file, but few of us will skip the infect and use load methods. Any swithich variable is not needed.

So fugitive, for example, will work just fine without Git, up till the point you explicitly invoke a command.

I want to mention plugins which "run all the time". For example YouCompleteMe which provides code completion. This kind of plugins have no choice than print errors at the time they are loaded. When call pathogen#infect() is on the table, we can try-catch loading it, and when it fails, use alternative plugins or settings. Real use-case: YouCompleteMe fails, use supertab and jedi-vim which can almost substitute its features.

But of course, its your code, so your last world :-). I am just trying to suggest you, what I think it can be good.

@tpope
Copy link
Owner

tpope commented Jul 7, 2014

You can call pathogen#interpose('bundle/YouCompleteMe') to add a single bundle to the runtime path. Is that what you're really after?

@FrostyX
Copy link

FrostyX commented Jul 8, 2014

Exactly. I was just trying this function but probably somehow wrong cause it didnt work for me, but now copy&paste worked. For convenience I would prefer pathogen#load('YouCompleteMe') but this is it. Thank you

@hermeszr
Copy link

hermeszr commented Dec 9, 2014

A problem I had with plugin loading is that from time to time I wanted to disable plugins, either for checking other plugins or disable something temporarily. Instead of disabling a plugin by altering my .vimrc, I preferred a file system solution which will not require me to change my .vimrc. For that purpose I've developed PathoMan, which manages enabled plugins by creating a hidden folder with "disabled" plugins which will not be loaded by pathogen#infect().

Perhaps pathoman can help you manage plugins that are loaded (That is, simply disable all plugins which you wish not to be loaded).

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

No branches or pull requests

4 participants