>starting new thread.
Thanks.
>Why does VAM cause that impression? The doc illustrates the minimal usage:
> set runtimepath+=PATH-TO-VAM
> call vam#ActivateAddons([.. list of plugin names ..], {'auto_install' : 0})
>and that's pretty minimal.
Yes. It is minimal. But it seems to configure plugin setting is diffcult.
And I have over 100 plugin settings. Can your configuration manage them?
>The more complicated code just contains some additional settings and
>code to checkout VAM (bootstrapping it).
Yes. It also can do in neobundle(said Marcel).
>Even more VAM ships with a bundle emulation:
>The comments look like this:
>The emulation is not complete due to lack of time.
Oh, I don't know this feature.
But this feature cannot support NeoBundle features...
>> It is like snipMate vs xptemplate problem.
>VAM can emulate vundle. But xptemplate/ultisnips cannot simulate each
>other because they are very different.
It may be different. But the emulation does not means VAM has backward
compatibility for Vundle. NeoBundle has it. It is not emulation.
>> I think "duplicate plugin managers" is OK.
>I agree - if there is a reason. Not having known about VAM is not a good
>reason to duplicate such a huge effort.
> Of course that can be a good reason. Shougo probably could have known VAM
> existed if he looked for it, but if you look and can't find, you will never
> be sure something does not exist. With everything you program you possible
> are just duplicating someone else work. And it is not just duplicating. It's
> another flavour.
Yes. In the world, the many plugin managers are avalaible. For example,
vim-flavor, pathogen, vundle, neobundle, GetLatestVimScripts, VAM, vim-plug,
and so on. We cannot integrate it. Because, the plugin managers may stop
development like Vundle or fork it. We must be free.
>
> I don't know about advantages of VAM over NeoBundle, maybe there should be a
> page on the wiki to compare VAM and NeoBundle in details, the prons and cons
> of each one. VAM and NeoBundle seem to be the most complete plugin managers.
> What can NeoBundle do that VAM can't?
> What can VAM do what NeoBundle can't?
> What is the difference in usage?
OK.
neobundle has not these features:
1. archives support(needs for support vim.org plugins)
2. VAM-kr compatibility(working)
3. bazaar, darcs support(it is needed?)
4. update hooks in each plugins
5. json support
6. more plugin information for example: deprecated, ...
VAM has not these features:
1. advanced lazy loading(Because, to implement lazy loading is not easy...)
2. unite interface
3. neobundle#tap()
4. default option
5. direct install
6. advanced user settings for each plugins
>
> > > User should choose your own plugin manager.
> >
> > Of course. Thats' the second goal I have: Make it easier for users to
> >
> > choose the right tool if there are multiple choices which is why I
> >
> > welcome everybody to join my wiki.
>
> That is why the focus in this thread should be on a standardizing plugin
> information in one repository, which all pluginmanagers can use.
>
> You seem not to be completely consequent. You invite everybody to your wiki,
> but you also want to know why Shougo wants to continue his work on NeoBundle.
> You suggest NeoBundle can be emulated by VAM. Even Vundle emulation is not
> complete and VAM is missing features to be able to emulate NeoBundle. You say
> you want choice, but it seems also that you want just one definite
> pluginmanager, which would be VAM of course. You worked for years on it. I
> understand that.
>
> Let's focus on creating a standard plugin information pool. That most
> important.
> One pool to rule them all. :)
Yes. I want to discuss for it.
The plugin managers may stop development. But the standard plugin information
pool is not. So it is too important.
For example, in ubuntu, apt-get, aptitude, syntastic, Ubuntu package manager
use same repository pool. Users can select package manager.
www.vim.org may be the standard plugin information pool. But it is too hard to
use by external tools.
vimscripts.org is better. But it stops development...
VAM-kr is great pool. But it is not general plugin management pool. It is for
VAM.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
