> > 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 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) 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.
