Excerpts from Benjamin Klein's message of Fri Feb 14 13:24:52 +0000 2014: > My point is that I'm probably not even taking full advantage of what Vundle > can do, and yet it's never been hard for me to use. I don't think featureful > == hard to use. Vundle has different design choices. Eg it doesn't tell you if a plugin you want is missing (unless you run BundleInstall) - Shougo "fixed" that by introducing NeoBundleCheck - however using VAM everything is right by design - if a plugin is missing the VAMActivate just checks it out.
Its a small difference, and I've filed a bug against Vundle (for this reason) - to think about why it is the way it. Vundle is fun - unless you happen to hit these issues: same names at vim.sf.net cannot be used: #183, #323, #173 The fact that there are 3 bug reports for one topic talks for itself (sry). > > Everybody has their own preference for how few or how many features they > > want. That's why I believe efforts to get everybody to use one single wiki > > / plugin manager / whatever are unrealistic. I think what really would make it hard to get everybody to use a > single tool would be that there are several established ones now, and > maybe most of their users would be uninterested in changing to > something else. If, however, the developers of some of the popular or > older (etc.) ones could join together That's what I'm trying. I even offered gmarik to continue vam's engine under the name vundle .. his reaction was "you can help with vundle" - and if I did i would turn it into VAM - which is why I cannot do it. What I did is reviewing all bug reports for Vundle extending VAM so that some of those issues (such as version lock) could be implemented easily now. (only the git checkout .. commands are missing). The main problem is not that something (eventually) went wrong, the main problem is that its likely to happen again - beacuse we don't have a single source of knowledge to lookup existing solutions (if people still prefer to write their own stuff for arbitrary reasons I'm fine with it - but then they can document why they do it !) Current situation exists because vundle was started and Shougo "fixed" Vundle by turning it into NeoBundle (without knowing about VAM). I'm waiting for Shougo to tell me how much benefit parallel installation really has - so that I understand whether I should push this feature, too. So I'm trying to collaborate on - unique interface to declare plugins (having one command so that its easier to switch - VAM already has a somewhat working vundle emualtion, some details are missing but are trivial to fix) - a plugin pool which can be searched (vam.mawercer.de is for Windows users and to lookup sources), vim-scripts.org (suffering from mapping differenct script ids but same title to the same keys ) - joined effort to cerate a website (vim.sf.net - and plugin search!) - mark plugins as "depracated" if there are strong reasons. This still should allow users to install them - but tell them that there might be better alternatives (to fight against the problem what used to be good doesn't neet to be the best solution tomorrrow - but stars and votings will tell you something else) vim-wiki is one attempt - and you probably alos have seen the other thread that I'd like to move some wiki features to important pages on vim.sf.net (because I cannot / don't want) to rewrite vim.sf.net for many reasons. > maybe their users would follow. (I would.) > because we have different preferences for how many features we want, > we need a different plugin manager (or whatever) for each Vim user. Yes - but wouldn't it still be nice if all plugin managers would support Script 'foo/bar' syntax? At least tons of README's could be simplified to: " Script explanation/syntax see http://wiki-url " dependencies: " Script 'dep1/baz' " Script 'dep2/baz' Script 'foo/bar' and it would just work whatever manager you're using. Discuss at: https://bitbucket.org/vimcommunity/vim-pi/issue Reasons behind this proposal is that I get install patches like these: https://github.com/honza/vim-snippets/pull/307 (Think about having 5 managers and 4 plugins and maybe some optional dependencies or different dependencies like in the vim-snippets case that would make a long page telling about how to install something) Currently most plugin managers implement their own kind of "shell" dsl, because writing quoted commands in Vim is hard (shellescape etc, see vundle issues) - this one issue was reported / asked about 3 times (none of those issues got closed) So another thing to think about is what about moving what have achived into vimruntime ? (Another story) But new vimruntime's must be stable, because you cannot easily replace them on many systems .. (Just some thoughts) 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.
