On Dec 28, 2013 9:01 PM, "Marc Weber" <[email protected]> wrote: > > > > That is a nice feature, but as it is limiting the use of unmaintained > > packages it's not for me. I'll take the risk if I use unmaintained > > packages. > You can always take the risk. The difference is that a small message is > shown, such as "this plugin is is outdated, try xy instead, continue > [y/n]" - so you always have full control. > > > said before it also limits the number of packages as long as not every > > plugin developer follows that guideline. > You're wrong. The pool is made up of > - a dump from vim.sf.net - thus its always accurate and up to date > - manually mantained set of github urls for packages which get > contributed
Set of SCM URLs is *mostly* no longer maintained manually. There are some URLs maintained manually and there still will be more, but autoget.py now handles the great part of plugins; almost all new URLs come from autoget.py. Note that for every person who has an idea about how boring it is to maintain such pool "manually maintained set of URLs" is a disadvantage. And also do not forget that we do not have a set of *github* URLs. Supporting non-github SCM URLs is one of our advantages over some plugins. > > Then its you who can customize the function merging those sources or > adding additional name <-> repository information. (or use > 'github/name/repo' shortcuts when installing) github:name/repo if I am not mistaking. > > We don't want to limit the user in any way. > > If a package needs patching (eg different runtimepath in subfolder) > an addon-info.json file is written by VAM for that package according to > this patch info: > https://github.com/MarcWeber/vim-addon-manager-known-repositories/blob/master/db/patchinfo.vim > Thus all of those still work ! > > The goal of VAM is to make using of plugins as painless as possible - > not to limit the freedom of the user to do what he wants. > > The other goal is to provide a pool of packages, which in theory could > be reused by other distribution systems such as linux distributions. > It just happens that the info is encoded in text files in a git > repository because it was fastest to get started. > > The real question is: How can NeoBundle and VAM collaborate? Even if > some parts are implemented differently, dosen't it make sense to > collaborate on "installation instructions" etc ? > > addon-info.json was meant to provide such. So I welcome all plugin > solutions to join. > > > git/hg NeoBundle does too. > I know, see my wiki. Sry if I forgott to change my mail before sending. > > > > VAM and NeoBundle have different target users. VAM goes for quality > > management of the plugins, NeoBundle is for the users who want to have the > > most options. > You got a bad impression. VAM allows you to opt-out from the default > pool. Then only code is left doing whatever you want. > > Eg you can also install by 'github/name/repo' and be done, too. > > Just for my packages (eg vim-addon-async vim-addon-actions etc) it does > make sense to encode dependencies without having to ask the user to take > care - because there are many - because I prefer modular reusable code. > > There are situations about optional dependencies, and here the user must > explictly install them. It would be wrong to hardcode them. > > > lazy loading deserves to be mentioned > I did, see my wiki. > > VAM has had support for lazy loading since 2012-02-27. We don't have > dummy mappings yet - but that's a trivial task to add. > > Neobundle: > > 2012-12-29 10:29:16 - Implemented autoload mappings. > 2012-12-29 07:45:30 - Implemented autoload filetypes. > > So VAM has been earlier here, too (but less complete, because it missed > mappings) > > Fine, I accept diversity and rewriting is good - I accept that NeoBundle > is competitive. > > Marc Weber > > -- > -- > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
