Excerpts from marcelspostbakje's message of Sun Dec 29 19:53:51 +0100 2013: > I personally prefer the Vundle way. Please let's not even start discussing unimportant details. Of course VAM is fine with you using
call vam#ActivateAddons(['plugin1']) call vam#ActivateAddons(['plugin2']) In fact VAM also defines ActivateAddons plugin1 plugin2 ActivateAddons plugin2 plugin3 command. That both VAM and NeoBundle go beyond simple vimrc has been shown, eg by allowing to lazily load plugins. That for instance does make a bigger difference for users having many plugins (startup time). > It is still emulation, you can use EMACS with evil-mode too. > Why emulate ? To make switching to VAM easier, because it provides some features vundle does not, such as loading plugins at runtime, true *dependency management*. To make you understand once and for all *why I wrote VAM*: to make installing such plugins seamless: https://github.com/garbas/vim-snipmate/blob/master/addon-info.json current snipmate depends on tlib (for selecting snippets to edit) and vim-addon-mw-utils (which implements caching). I want modular reusable code. This may not bother you as end user, but it bothers devs. The other thing is that VAM tries to make the common usage most simple: Allow using "a simple name" and be done. It still allows you to do what you want. Neither Vundle nor NeoBundle do that. > real thing Why emulating if the real thing is available? You're mixing apples and potatoes. I've only been talking about as small "user interface layer", which dosen't make a big difference. Emacs vs Vim vs XY is something totally different. Eg I don't want to use Emacs for trivial reasons such as making window smaller is forgetting about splits and so on - and those issues also apply to Evil. I've tried switching to Emacs, but rewriting everything I had would have taken too much time. So if you're talking about the "real" thing also say why something is "real" and the other is not. If you talk about "you must have good reason to emulate" explain why? If its cheap why not just do it? VAM already does have - abstraction about where your plugins are stored Thus emulation just replaces one function by another changing directory names. It doesn't make a big difference. > I don't see any reason why I should prefer VAM with NeoBundle to NeoBundle > itself. Then don't. If you don't need lazy loading, if you don't need activation at runtime, if you don't need to checkout SVN repos, if you don't need to create a setup fast by using plugin name completion in .vimrc, then be a happy Vundle user. But even in your case VAM would serve you, too. > like synchronous updates. A shell script running git pull in parallel can be written in 3 min. > 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, http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html This is meant to become such a page. (and not only for plugin management, join and contribute!) Look, its not about VAM vs NeoBundle, its about NeoBundle was started because the author didn't knew about VAM! And that's a big issue in the community I've been faced over and over again. We need to fix that (maybe by introducing a haskell like activities and communities report talking about news - now that most plugins get changed on github). That's what I carre about! > What can NeoBundle do that VAM can't? > What can VAM do what NeoBundle can't? > What is the difference in usage? The biggest difference is "design". VAM was designed by me to serve the community by not only giving the user the freedom to do what they want, but also to provide a way to guide them (eg by telling them that they may use plugin X, but that they eventually want to look at Y, too). I've replied to people on irc maybe 10 times telling them that Sanders plugin is outdated, or that pyflake-something can be replaced by syntastic and all problems will be gone. If a plugin is known to cause "security" issues, we can fix or mask them. (Didn't happen, but having two contributors like me and ZyX) makes it very likely that actions would happen in a very timely manner. > 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. Well - that time I've been on irc almost daily advertising it. VAM has been on vim.sf.net for a long time. Let's keep the story short. Me and Shougo both would like to spend our time on more important things. So something is going wrong, so we have to talk about it. > program you possible are just duplicating someone else work. And it is > not just duplicating. It's another flavour. No, when I started VAM, no plugin manager existed which was able to manage dependencies. Something I need to push both: my plugins and the community. That time I was reading comments in other plugins like "This code duplicates file which can be found in plugin FOO, just because its too much pain to tell users to install two plugins". I forgott about the plugin name. But that was the reason why I stepped up to solve this problem. > That is why the focus in this thread should be on a standardizing > plugin information in one repository, which all pluginmanagers can > use. I agree. But this requires Brams action because it eventually require rethinking hosting. He didn't reply for ages about whether he'd allow moving to a different sponsored hosting. sourceforge is limited. Eg in the past it was not possible to send password reset mails (maybe it is possible today). > 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. Yes / no. I'd like to merge if possible/feasable to minimize time we bothh require to maintain code in the future. > 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. I suggest thinking about it. I'm also willing to give up VAM, too. At the moment I cannot because it has true unique features which are much more important than what NeoBundle allows: Eg the reading addon-info.json files allows plugin users to maintain dependency information without me or anybody else having to care or review plugin receipes. Thus while recipes get the job done, they will just cause more work to me. So its no option for this one reason. > Let's focus on creating a standard plugin information pool. Because I at least tried starting such an attempt should tell you that I did care about that. It was also me patching vim.sf.net to export a list of all known plugins. So maybe the way to go is make a list of features, ask users which they care about for what reasons, and then decide about how to continue. I'm fine with diversity, eg haskell.org also has at least two code search engines. However the main entry page also talks about them, wheras Vim has multiple entry points: :h -> does neither talk about Vundle/Pathogen/VAM/NeoBundle vim.sf.net -> does only talk about them if you do a lot of research And that is to be fixed, too (IMHO) At the moment I don't have time to think about all this - there is more important work to be done for me. 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
