> line' I was referring to Vim's command line mode, not the terminal. > I'm sorry for the confusion. So it looks like the wish to use /bin/sh to install plugins using shell is not as huge as I thought - so no need to rewrite parts of VAM or duplicate implementation. (lucky me)
> Something similar to having the system version of Vim in /usr/bin and > the one I compiled on /usr/local/bin. Let's say I have two dirs, one > is a shared one maintained by someone else (A), the other is the one I > maintain (B). So, say I modify one of the plugins available on the dir > A and I put on B, then I'd just disable the inside A and leave the > other one working. What exactly are you talking about? Standard installation or standard installation and custom plugins? VimL plugins are so cheap (in size and file count) that it should'nt cause any trouble having a full copy of all plugins for each user. So there should be no need to use directories managed (and patched) by someone else. The way to go is ask that "someone else" to push his scripts to a public mirror (eg github) so that you can check them out into your directory easily. - You'll have a backup on a different host - you can patch it to make it fit your needs - ... So make me understand why the solution of picking some plugins from one directory and others from another directory is so appealing to you? VAM could have a g:vam_list_of_paths_containing_plugins so that you can add both, the (A) and (B) directories. However I'm still curious why you want to have so much sharing. If there are two users sharing the same account you can still use symlinks: mkdir vam-addons1 mkdir vam-addons2 git clone plugin1 vam-addons1 ln -s ../vam-addons1/plugin1 vam-addons2/plugin1 Then both directories access the same "plugin1" contents. > But I don't think this is a big deal now, you guys have made me think > and it doesn't sounds as important as it did. Right now I could just > put my B dir before A, so its content takes precedence, just like with > $PATH. That should be enough for most cases. > So, I can disable a plugin with the following command from Vim: > :Plugin disable pluginX Can you talk about this plugin? Why don't you load it always? Maybe there are additional solutions. > Something like that, since I might not have write access to any of the > dirs, the list with all dirs with their plugins is written to > ~/.vim/bundled_plugins, one item per line. So would symlinking those "foreign" plugins into your plugin dir be an option? > It shows, I'm really impressed and thankful for all the work you guys > have put into making VAM what it is. Thanks :) I'm asking so much because I'm concerned that one of documentation, advertising or communication was not good enough in the past leading to many duplicated work. That's why I started this thread.. So thank you for taking the time talking about your concerns and use cases. ZyX: I only talked about adding directory prefixes to find more about these use cases. Thinking about it a second time clearly shows that it would cause more issues than it solves. So this won't be the reason causing you to start a rewrite :) Marc Weber -- You received this message from the "vim_use" 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
