Using VAM breaks usage of unmanaged plugins

[oblitum]

First time using VAM. Meanwhile, sometimes, I want to test some unmanaged plugin (by putting plugin files in .vim), while still using VAM, is it possible?

This is my .vimrc, I'm doing this test only with VAM with a single managed plugin (NERDtree, but it could be any), and another single unmanaged plugin (Rainbow Parentheses Improved):

set nocompatible
filetype indent plugin on
syntax on

set runtimepath+=~/.vim/addons/vam
call vam#ActivateAddons(['github:scrooloose/nerdtree'])

let g:rainbow_active = 1 
let g:rainbow_operators = 2

With this, I get a bunch of already defined functions for the unmanaged plugin, as if it was being loaded twice. I get a bunch of error messages for that on VIM launch.

When I comment the single call vam#ActivateAddons line, the errors don't happen.

[MarcWeber]

Hi Francisco Lopes,

Have a look at the documentation, it cleary states that 1) a plugin is fetched if it does not exist on disk yet 2) its activated. Thus creating a directory, putting there your "unmanaged" files and adding the directory name to the plugins to be activated is all you need. If you don't talk about your errors there is not much we can do.

About sourcing twice: 57b70b3 introduced something which may have caused what you're experiencing. An option was added later and is disabled by defaults. Thus make sure you have latest VAM. I can't reproduce it. the plugin file of nerdtree as show in your case is loaded once only

My experience is that using fun! and the reload plugin is the fastest way to develop in VimL. fun! replaces the function

If you still have trouble with latest VAM, then contact me again, then we can debug this issue on my server.

[oblitum]

@MarcWeber This is the lastest VAM, I started building a fresh VIM environment last night. I'm doing this test just like I said, 3 things, VAM, a VAM addon (NERDtree, but the error happens when any addon is activated) and "Rainbow Parentheses Improved".

Rainbow is just a single vim script to be put in the plugins directory, so I've done just that, it's in .vim/plugin/rainbow.vim.

It works without problems alone, but when I uncomment the VAM plugin activation line, it mess with the unmanaged plugin. I really don't want to edit the unmanaged plugin because of VAM.

[oblitum]

by the way, I've not tried what you said about putting the unmanaged addon in it's own directory and telling VAM to load it, like in .vim/addons/vam/rainbow/plugin/rainbow.vim right? (can I load it from any dir, e.g. .vim/rainbow/plugin/rainbow.vim?)

It may be a way out, but in truth doesn't solve the mentioned issue.

[oblitum]

just tested putting rainbow in .vim/addons/vam/rainbow/plugin/rainbow.vim and loading it by call vam#ActivateAddons(['rainbow']) and got the exact same issue.

[oblitum]

This way, the errors can be triggered by loading rainbow solely.

[oblitum]

just checked, changing func to func! avoids the problem. I say avoids and not solve, because it's really a VAM problem given that the script works on its own. I really don't expect to get my hands dirty by editing plugins just to work with VAM though...

[ZyX-I]

My experience is that using fun! and the reload plugin is the fastest way to develop in VimL. fun! replaces the function

Using guards is far safer and is just as fast. You can’t expect plugin reloaded by resourcing after update to be consistent (especially if nobody cared like you do with let s:c.option = get(s:c, 'option', …)) and there is no need in resourcing if no update happened.

I prefer guards and my own reload mechanism as I can do necessary job like clearing temporary files, reloading python modules, triggering dependency reload, but this is definitely not the fastest way. Though I am sure my plugins are always consistent.

// The problem occured earlier that led to that option was due to my own implementation of autoload feature which is still used by some of my older plugins. Obviously it was not a good idea, especially with such fragile implementation.

---

@oblitum Check whether :scriptnames output contains shortened (~/.vim/…) or not shortened paths. If they are shortened then the problem is vam#SourceMissingPlugins and is probably solved by this changeset. It should also be “solved” by setting no_activate_hack option to 1. I think it is good idea to either merge that branch (may introduce performance issues) or revert.

[MarcWeber]

I have sent you an email asking you to contact me by skype or irc.

[MarcWeber]

Closing this issue cause you haven' contacted me. Without knowing all the code you're using there is no way reproducing such a bug. If you still need assistance or want to figure whether this is a VAM bug at all you can contact me at any time.

[oblitum]

What?, I really don't want to chat. I don't use skype (and I think I'll never use). I think stuff should be solved here, it's a good platform.

All the code I have is this. I'm on Mac, using MacVim. Completely fresh install. I'm testing your VAM so I have only a minimal .vimrc just to test it, identical to the one I present above.

I can try to load from file just a single addon (Rainbow Parentheses Improved), and it will present the problem I said. The plugin doesn't present such problem when loading by itself the old way. The problem I think is specific of this plugin given it doesn't define its functions with func!, just func. It seems VAM is unable to deal with that.

There's no more to say, no added information, it's all.

[oblitum]

This problem can only be with VAM, it's not only about a minimal .vimrc, I really have no other plugins in my .vim directory. It's VAM and these tested "addons" solely.

[ZyX-I]

There's no more to say, no added information, it's all.

What about answer to my questions:

1. Check whether :scriptnames output contains shortened (~/.vim/…) or not shortened paths.

2. Is it solved by checking out smp-fix branch or setting no_activate_hack option to 1? (In that vimrc it should be set with

   let g:vim_addon_manager={'no_activate_hack': 1}
   call vam#ActivateAddons(…)

   .)

---

@MarcWeber It looks much like a problem I already reported. Now that it bugs not only me and not because of poorly written autoload reimplementation I see no reasoning in closing this bug.

[oblitum]

Hi @ZyX-I, yes, there is shortened paths. I've tested the easer fix you mention and setting no_activate_hack doesn't trigger the issue =)

[oblitum]

What does this no_activate_hack option enables or disables, since it's not referred in docs?

[ZyX-I]

@oblitum VAM by default sources files in plugin/ subdirectories in runtimepath in case they are not present in :scriptnames output. It is done on VimEnter event and is targeting the situation when addon activation function was called not from vimrc, but from some plugin/ script somewhere in a runtimepath. In the described case (i.e. when runtimepath is modified after its processing was already started) some plugin files may be skipped and not loaded.

[MarcWeber]

It didn't happen to me. I now used a chroot by chance reusing my setup - and I got the same kind of issues. Sorry for being that ignorant. It'll take me little time to review what ZyX did and to investigate. ZyX: In the future try not to use negated config options. use 'activate_hack' and set it to 0 by default instead. Having to much negation is what I'd consider complicated style. I'll only reply again if ZyX didn't fix this issue yet.

[MarcWeber]

no_activate_hack got renamed to source_missing_files, I added more documentation talking about why it exist.

[ZyX-I]

Name no_activate_hack has much worse problem then negation: when looking at option you have no idea what it does. I renamed it due to the same reason I renamed vam#Hack (in fact, I’d’ve never consider this name after renaming the function because it refers to the old function name).