Think about what we did wrong and how to continue

[MarcWeber]

Despite VAM works great we did something wrong - user estimations (2014-02):
vundle#rc hits @ google (approx 272.000 hits)
vam#ActivateAddons hits @ google (approx 800 hits)

ratio (google hits): 340
star ratio (github): 13
fork ratio: 9

Maybe I've been mistaken and nobody wants a managed pool of plugins, maybe we didn't care enough about README.md ...

Anyway - time to think about how much additional time to spend on VAM ..

[Shougo]

vundle#rc hits @ google (approx 272.000 hits)
vam#ActivateAddons hits @ google (approx 800 hits)

I tested it by neobundle(approx 27000 hits, but most of them are Japanese entories)

I think VAM's concept is good for example dependencies, plugin information, many VCS support, vim.org support, but the configuration is different from Vundle.
Users must pay the migration cost.
neobundle is not, but neobundle also has smaller users than Vundle.
I think Vundle's feature is simple and good enough for most of people.
Although neobundle has many features, it is complex plugin manager like VAM.

[Shougo]

Anyway - time to think about how much additional time to spend on VAM ..

It is difficult problem. But I think vim-pi concept(plugin information repository) is important than VAM.
People may use different plugin managers(VAM, Vundle, neobundle,...), but they should use same repository information.

[steveno]

I realize that as an open source dev you always want a large following, and that when you're not named Linus Torvalds people just don't follow you by default (ie his stupid diving app that everyone was excited about even though you know none of them dive). I assume no one would use git either if it weren't for him. It's great, I guess, but no more special than mercurial for example.

Anyway, I hope you keep the project going. You've got great work here. gmarik has effectively bowed out of vundle. I now question the future of that project personally. I'd hate to lose VAM too.

[Shougo]

Yes, the selections are important. Although smaller than Vundle users, VAM has many users. VAM don't have to stop the development(neobundle don't have to stop, too).

[glts]

I've seen your messages on vim_use, @MarcWeber, and I get the impression that you are pretty disappointed.

But 300+ stars on GitHub isn't too bad – and I agree with @Shougo that you have something extremely important going on with vim-pi: the central plugin info repository. That is something that eventually all plugin managers might depend on. Maybe put a priority on that for the time being?

[MarcWeber]

@Shougo vim-pi concept(plugin information repository) is important than VAM.
You were missing a "more than" here :)

I agree - which is why I pushed exactly that question - how vundle wants to implement dependency management - and whether we can collaborate

gmarik did care enough to close / move an issue:
VundleVim/Vundle.vim#241

@Shougo: VAM does already implement a vundle emulation, getting the {rtp: .. } stuff work (second argument to commands) would be doable, we could have a second rtp in VAM thus not much would change for vundle users. We could there easily ..

@glts: Its not only about followers, also about trying to find the best way to maximize benefits (that's what open source is for ..) - and about talking to each other.

If Vundle would adopt vim-pi (and having names rather than github pointers) - then it would turn into VAM (minus other VCS support). And that's the problem. I even offered switching name of VAM to vundle in that issue 241, gmariks action was closing and reopening the issue saying "he wants to solve problems, not creating them".

Please also read the "why vim sucks" section on vim-wiki.mawercer.de. I do not only worry about VAM, but also about Vim and its community (Emacs has more users anyway). If I would have known all the trouble maybe I would have learned Emacs. I chose Vim for 'less stress to finger" reasons without knowing better that time lol. It still serves me - switching would be too much pain

I'd even join vundle, but it doesn't make sense because VAM has everything vundle has (feature wise). Even though my mail to vim-use didn't get much replies we have to push the community idea even if not many will join - those who do will benefit.

[Shougo]

I agree - which is why I pushed exactly that question - how vundle wants to implement dependency management - and whether we can collaborate

I don't know whether the dependencies feature will be implemented in Vundle.

VundleVim/Vundle.vim#384

@Shougo: VAM does already implement a vundle emulation, getting the {rtp: .. } stuff work (second argument to commands) would be doable, we could have a second rtp in VAM thus not much would change for vundle users. We could there easily ..

If VAM can compatible with Vundle like neobundle, users may do not change plugin management system.

I'd even join vundle, but it doesn't make sense because VAM has everything vundle has (feature wise). Even though my mail to vim-use didn't get much replies we have to push the community idea even if not many will join - those who do will benefit.

I think Vundle is more simple and stable plugin management system than VAM and neobundle.
So, it is less features than others. It is directional difference.

[MarcWeber]

Shougo: What do you mean by "more stable"? On the other thread you've said "I don't think VAM is ready" ? What is your impression based on? Maybe you should give it a try once before making such statements.

[MarcWeber]

The really funny thing is: given enough users they also get close - some PRs never got merged like this supporting additional VCS: VundleVim/Vundle.vim#134

[MarcWeber]

#241 contains some "Easy to fix - for starters" issues people who want to help but don't know where to start could start with ..

[Shougo]

Shougo: What do you mean by "more stable"? On the other thread you've said "I don't think VAM is ready" ? What is your impression based on? Maybe you should give it a try once before making such statements.

Vundle has less features and changes than NeoBundle/VAM.
So I think it is more stable. Unfortunatelly, if you add features, it will be more complex and less stability.

[MarcWeber]

ZyX has done some work on implementing tests. Install/updates are used often, so regressions would be caught fast (even in the VAM case). The last time something trivial broke we had an issue within 48h or less.

By the way computers generally fail because there is cosmic ray - so why are we using them at all? :) Multiply this by the amount of lines the linux kernel has - multiply it by the amount of for (c = 0; c <= count; c++) usages in the kernel (I found 2-3 cases when using a simple grep the last time ... (of course it should be < not <=). You're right - that's why I don't want to add parallel install - because then I'd start using Vim the way it was not written/tested (I had and have enough issues with vim-addon-async which uses client-server feature ..). Counter measure: We have 4 eyes reviewing code (mine and ZyX) - and that's proofen to cause less bugs. So which argument is stronger? .. :) You're right in the general case - but given that Vim is buggy by design (eg resize issue) (vim-wiki.mawercer.de -> why viml sucks) .. I don't think we should think about starting such a discussion here.

[Shougo]

You're right in the general case - but given that Vim is buggy by design (eg resize issue) (vim-wiki.mawercer.de -> why viml sucks) .. I don't think we should think about starting such a discussion here.

Vim may be broken. But, to rewrite Vim will break more and more.

[thet]

@MarcWeber thanks for creating VAM and vim-pi! that was my only vim plugin manager for years, but now i'll give vundle a try.
it's a bit tedious to fork/pull-request every time i want to try out a plugin not available in the VAM/Pi list, like this one: https://github.com/tpope/vim-vinegar. also, is a lot simpler and leaner than vam, which is not a drawback. vundle seems perfect to support the use case of adding a repository just found on github. unfortunately it doesn't support hg and others, but that seems to be fixable.
i can't say if i stay with it or switch back to VAM. time will tell.

[ZyX-I]

VAM does support repositories not in vim-pi.

20.04.14, 13:44, "Johannes Raggam" [email protected]":

@MarcWeber thanks for creating VAM and vim-pi! that was my only vim plugin manager for years, but now i'll give vundle a try.
it's a bit tedious to fork/pull-request every time i want to try out a plugin not available in the VAM/Pi list, like this one: https://github.com/tpope/vim-vinegar. also, is a lot simpler and leaner than vam, which is not a drawback. vundle seems perfect to support the use case of adding a repository just found on github. unfortunately it doesn't support hg and others, but that seems to be fixable.
—
Reply to this email directly or view it on GitHub.

Sent from Yandex.Mail for mobile: http://m.ya.ru/ymail

[MarcWeber]

@thet

1. you can contact us by mail
2. you can contact us by irc
3. you can file a bug report
4. you can do RTFM and find that VAM supports "github:name/repo" shortcut which
   is also contained in README (or simply grep the source code). If you feel this is too long
   consider creating an issue proposing to support 'name/repo' only - because I agree that github is used most often.
5. Thanks for contributing those two changes to vim-pi - we love you for having
   done it :)
6. vundle does not offer any important feature VAM does not offer AFAIK.
   If you feel differently please tell me. vundle is stateful. If you really
   prefer that .. Eg see this issue: Consider making vundle to be declarative (as VAM is) VundleVim/Vundle.vim#388
7. contributing a pull request might seem to be much effort, but think about
   the value vim-pi could provide to you if you start using an outdated plugin and it
   allows you to do so - but also tells you? That's why I initially created that "pool",
   because I got sick about replying to the same questions on irc "why dosen't plugin A
   work because I've seen it on blog B".

In the long run we would like to merge - but it doesn't make sense to work on
it right now because neovim is evolving. My statement to gmarik was clear:
I would contribute to vundle, but it would mean turning Vundle into VAM.

Anyway, I'm all for 'let the user choose what fits his/her/its needs', thus I
created this summary page:
http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html
If you that it is verye biased just edit and improve it. Take care about the VAM sample
on that page, it shows how to use vam#Scripts which allows to declare scripts in a plugin manager independent manner - but neither Vundle no NeoBundle tried following yet (Even though I asked both what about adding a "Script foo/bar" like command so that we all can support it getting rid of the long install instructions for manager FOO in all those README's on github. Thus I'vie tried what I think is best - the ideas failed - hopefully they'll be picked up in the future.

VAM is missing: "fixed hashes", "parallel installing". The first could be
implemented easily (everything is prepared), the second is implemented by
NeoBundle, and I don't want to add such features because current Vim is bad
at async. See 'http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-suck.html'
for instance or vim-addon-async's documentation - again - neovim wight fix this all.

This is only my view. If you have evidence that I'm wrong please tell me.

[RedX2501]

Well i had the choice a few days ago.

I needed YouCompleteMe and took my time and read up on Vundle, Pathogen and VAM to decide which one i should use. YouCompleteMe mentions Vundle as an installer, so that is already a big bonus for them.

I work on cygwin so any mention on how to do stuff on cygwin is a big bonus for me. In that category all fell short.

Pathogen fell out rather quickly as everywhere it is noted, that Vundle is (kindo of) the successor of Pathogen.

Then i read upon Vundle and it seemed very straight forward. 4 lines and a bunch of PluginInstall commands.

The i read on VAM. And after 3 lines i stopped ready and told myself "too complicated".

Main points that have kept me off:

1. In the Recommended setup (checking out VAM ..): section it is not entirely clear where to add the plugins I want installed. Maybe add a few examples. This is very clear from the Vundle readme.
2. The screenshot on the main page is not very well readable. Light blue on white? That does not agree very well with lots of monitors.
3. The screenshot on the main page shows some kind of popup. From personal experience getting some kind of popup on vi can be cumbersome and many plugins i tried with popups took lots of configuring to get them to work.
4. I'm behind a corporate firewall (NTLM) so it is very likely that getting any kind of information from a repo will be complicated. So there is no advantage is this for me.
5. After that comes a sentence with words like "lazy loading plugins/ tag plugins by regex". This
   sounds like a lot of work. Som questions that came to my mind:

• Can i do this with every plugin or must i figure it out by trial and error? (Sounds like work again)
• Do i need this by default?
• What is the advantage? Do i really save that much time?
• Can't this be done automatically?

(Force the list continuation)
6. lazily loading plugins / tag plugins by topic / pass dictionaries for adding arbitrary options The example does not tell me where the code fragment should go.
7. Vundle tells you quite clearly and the example how to add repos from github and vim-scripts. How do i do that in VAM without having to go through all the docs? Is it so complicated i have to read all the docs?
8. There is some talk on a repo. What happens if my newest plugin is not on the repo? Is VAM able to support it?

So i think that the primary problem here is the lack of a good concise introduction into VAM. It seemed to me that i would have to read a lot more just to get the basic functionality that i get with Vundle.

If you have a feeling that what you do is better than what Vundle is doing maybe you should make a section comparing against Vundle directly. Or a "in Vundle you do this" and "in VAM it goes like this".

Maybe a small migration section would also be nice.

[MarcWeber]

http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html
lists some differences and even more options

Then i read upon Vundle and it seemed very straight forward.
They have different design principles. VAM will throw an error if a
plugin you ask for is not installed (or will install it).
Vundle looks easy, but does not do it.

Vundle is based on vim-scripts which in the past had name collision
bugs. It has not been fixed yet:
vim-scraper/vim-scraper#65
(Maybe I'm outdated - should be easy to verify)

While vim-scripts is based on a scraper, VAM is based on vim-pi which
gets all info from vim.sf API (which I wrote for this purpose).

1. The screenshot on the main page shows some kind of popup. From
   personal experience getting some kind of popup on vi can be cumbersome
   and many plugins i tried with popups took lots of configuring to get
   them to work.
   So VAM, too? You're wrong. Its just a way to complete plugin names and
   it works out of the box. You don't have to use it.
2. I'm behind a corporate firewall (NTLM) so it is very likely that
   getting any kind of information from a repo will be complicated. So
   there is no advantage is this for me.
   VAM implements different ways to fetch github repositories, even
   fetchincg by .zip is allowed if you reconfigure it.
3. In the Recommended setup (checking out VAM ..): section it is
   not entirely clear where to add the plugins i want installed. Maybe
   add a few examples.
   VAMActivate plugin-A plugin-B
   or call vam#ActivateAddons(['plugin-A', 'plugin-B'])
4. After that comes a sentence with words like "lazy loading plugins/ tag plugins by regex". This
   sounds like a lot of work.
   Yes - do RTFM properly. There is "if you need more control" - maybe you
   just don't? ...
   • What is the advantage? Do i really save that much time?
     You can "bundle" plugins by tag, eg tell VAM: plugin-A,B,C are for
     c-development, and activate them for this project only (eg by using
     vim-addon-local-vimrc), which allows you to use a project local .vimrc
     like this:

call vam#Scripts(scripts, {'tag_regex': 'c-dev'})

Maybe you don't need it, so just don't care.

1. lazily loading plugins / tag plugins by topic / pass dictionaries
   for adding arbitrary options The example does not tell me where this
   example should go.
   Try to start thinking, then you'll understand the meaning of "call
   SetupVAM" ? Thus maybe just try adding it after that call? ^^
2. Vundle tells you quite clearly and the example how to add repos
   from github and vim-scripts. How do i do that in VAM without having to
   go through all the docs?
   You just do match to get matchit.zip completion. There are github
   shortcuts, eg VAMActivate github:user/name and so on, but we recommend
   using the human readable shortcut - because VAM maps plugin names to
   known locations (which vim-pi is about). You can escape and override.

BTW: VAM supports dependencies.. Eg installing snipmate will also pull
vim-addon-mw-utils (for caching) and such.

1. There is some talk on a repo. What happens if my newest plugin is
   not on the repo? Is VAM able to support it?
   See above, github shortcut. If you add an 'addon-info.json' you'll
   start enjoying the dependency feature for your own plugins as well.
   Things get as easy as
   { 'depnedencies': {'NAME': {}}}
   and the plugin 'NAME' will get installed automatically.

So i think that the primary problem here is the lack of a good concise
introduction into VAM. It seemed to me that i would have to read a lot
more just to get the basic functionality that i get with Vundle.
No, just copy paste the "recommended" setup, and have a look at "how to
find plugins names" in the help section ..

The future I want to work on will be know about multiple languages. Thus
you can install ocaml along with python enabled Vim in one go - but I
don't have for that at the moment.

Thanks for telling us - but a lot of your qusetions are "RTFM", eg you
might just search the site for github by typing ctrl-f 'github' to find
the short syntax.

[ZyX-I]

I still think that roughly 80% of stuff stored in documentation should be purged out of there and moved to the wiki. Including SetupVAM function, it looks too complicated. I.e. it is good to have

• Minimal working example. I.e. exactly one call to vam#ActivateAddons (_not_ :ActivateAddons: I do not want to explain how to get this command here), maybe one option setting and an explanation where VAM should be located for this to work.
• Full command, function and options reference.
• A list of most interesting github wiki pages with a brief summary about what is there. (Note “github”: your variant has bad design and a number of rendering problems (like lines longer than header highlights or line breaks clearly indicating that you just leave line breaks from original file).)

That’s all. Additionally README should contain the copy of the first point (“explanation where VAM should be located for this to work” should be expanded to installation instructions though).

[RedX2501]

What you are telling me Marc is probably 100% true.

If i were to look into the manual i would probably find answers to all my questions. But you failed to get me interested in your product. I failed to see the advantages to even try it out. No matter how well you documented everything if i'm just skimming over to see which LOOKS easier to use, you will loose.

Also i was looking for an easy to use solution, and if i have to look into some docs just do figure out how to get a git repo from github installed with your product it seems just too much trouble.

I'm not at home currently, when i get back i will try to learn more about vam and try to make a new readme that i think might make the features more prominent and the setup less obscure (sorry i cant think of a better word right now).

[thet]

maybe this discussion is getting a bit pointless, because vundle and VAM supports a different audiences. vundle for people who love easy and lean software and who find vim plugins randomly and by themselves - and VAM for people who like a vim package manager with a manged list of available plugins.
both software have their place and both are useful.

[ZyX-I]

@thet AFAIR it is not intended target audience of VAM: it is the same as Vundle one. @MarcWeber can say this for sure.

[MarcWeber]

RedX is true that installing from github is that common that it does make sense to make it obvious. Last commit fixes this. VAM can work without pool. Just define your own function returning an empty pool or such and use github:name/foo only if you really want

[bluddy]

Let me give you my take on this question. It's hard to say why some things go viral. A lot of it is just luck. However, the problem with vim is that there are too many implementations of the plugin manager which stand in the way to get to VAM. The benefits of VAM over the others are also not so obvious.

Users start with vim without any plugins. Soon, they hear or see some extra functionality and start adding plugins directly. They eventually learn that managing plugin files directly is a pain, and instead look for a plugin manager. They'll probably find pathogen first. After a while of working with pathogen, they realize they can do better. This is the opportunity point to grab them, but they can easily gravitate to more popular options like vundle and neobundle. Once they've chosen one of these, they're unlikely to switch from their behavior patterns. I only switched because I saw the advantage of a central repository and dependency tracking, but that's not something everyone can recognize.

To stand out as a 'killer feature', you need to do things only central-repository based managers can do. Copy MELPA. Show a nice window with all the plugins from within vim. Every plugin should have a short description. Allow the user to mark the plugins he/she wants to install/uninstall. Hide all the update work in the background (it's ok to freeze the UI for now, but a little text display at the bottom would be nice). With this kind of UI, there's no way anybody could doubt the benefit of a central repository.

[rprs]

I must agree with RedX2501. I have spent the past two days comparing between vam and vundle. Ease of use is vundle's killer feature when compared to vam. I've spent 90% of the time reading about vam and 10% on vundle. I'm still not so sure how to use vam (do I need to execute vam#update manually or does vam#activateAddons does it implicitly?).

I'm still going to give vam a try, I just want to reiterate the importance of ease of use. I believe it is the reason behind whatsapp popularity.

[rprs]

After a few months of using vam, I must admit I was wrong. Vam is pretty awesome. Specially when setting a new machine: just turn on vim and you will get all your plugins automatically downloaded and loaded. That's pretty slick!

I still think better instructions could improve ease of ramp up, but I'm a complete "vamer" now.

[nhooyr]

@rprs vim-plug can do that too. https://github.com/junegunn/vim-plug/wiki/faq

[MarcWeber]

I do no longer want to discuss 'which solution is good/bad' but whether it would be possible to share a common configuration so that you can switch implementations - because VAM is missing a concurrent installation/update system which could be added for "most plugins" which don't require viml hooks easily by putting plugins into a text file.

@rps "Activate" means "activate", "update" means update. Activate means "load the plugin and install if necessary". You can run install manually then activate in two phases if you want to look at the code first because in the end you're downloading "untrusted code from github". So adding "code review" from different parties would be nice have, but is out of scope for VAM and should be done on a different level.

@bluddy Having a window with all plugins means http://vam.mawercer.de/ -> huge list -> a lot of plugins are 10 years old and broken or outdated and does not help the user IMHO. We have name completion and command line completion. Creating such list is trivial because we have the dictionary with plugins ready. We could add a :ListAddons command, I agree.

AddonInfo shows:

  ===== by-name ===================================================================================================================
  Plugin: vim-addon-manager
  Script number: 2905
  Vim.org page: http://www.vim.org/scripts/script.php?script_id=2905
  Home page: https://github.com/MarcWeber/vim-addon-manager
  Source URL: git://github.com/MarcWeber/vim-addon-manager (type git)

We could work on adding description. Most value would be provided to users to see which plugins actually get used most often eventually or adding key values such as "got uninstalled within a short period of time" to help make a judgment about which plugins to try first.

Interactions (downloads) for that site can be seen here and there are not much for the time it exists.
http://vam.mawercer.de/previous_downloads.txt

[rps]

@rprs ^

…

On Wed, Jan 4, 2017 at 3:20 AM, Marc Weber ***@***.***> wrote: I do no longer want to discuss 'which solution is good/bad' but whether it would be possible to share a common configuration so that you can switch implementations - because VAM is missing a concurrent installation/update system which could be added for "most plugins" which don't require viml hooks easily by putting plugins into a text file. @rps <https://github.com/rps> "Activate" means "activate", "update" means update. Activate means "load the plugin and install if necessary". You can run install manually then activate in two phases if you want to look at the code first because in the end you're downloading "untrusted code from github". So adding "code review" from different parties would be nice have, but is out of scope for VAM and should be done on a different level. @bluddy <https://github.com/bluddy> Having a window with *all* plugins means http://vam.mawercer.de/ -> huge list -> a lot of plugins are 10 years old and broken or outdated and does not help the user IMHO. We have name completion and command line completion. Creating such list is trivial because we have the dictionary with plugins ready. We could add a :ListAddons command, I agree. AddonInfo shows: ===== by-name =================================================================================================================== Plugin: vim-addon-manager Script number: 2905 Vim.org page: http://www.vim.org/scripts/script.php?script_id=2905 Home page: https://github.com/MarcWeber/vim-addon-manager Source URL: git://github.com/MarcWeber/vim-addon-manager (type git) We could work on adding description. Most value would be provided to users to see which plugins actually get used most often eventually or adding key values such as "got uninstalled within a short period of time" to help make a judgment about which plugins to try first. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#148 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFANwhZS-0UTMx_TT0mFR3ScDpMZJUmGks5rO4BrgaJpZM4Bg9cH> .