You've been missing documenting default settings .. > Does not run ``&pythoninstallprg`` if bang was specified. May be counter intuitive. ! usually means "force it". I understand the idea "make things work by default". But i think it should be the user having the choice anyway.
> > - where it should install the python code to (eg ~/.vim/pip or ~/.pip) > Nowhere. It just calls pip and pip knows what to do. So you also have to run PIP on each startup ! And thats taking time eventually. No idea how much. > Anywhere reachable by pip. You can use > 'git+git://github.com/Lokaltog/powerline' as a second argument to make > pip install from that location. > > - who is responsible for setting rtp, so that syntax/* etc will work > We are talking about python-only plugins. What syntax/* or ftplugin/* > in case of python-only? The only option here is using Filetype and > Syntax events. > [...] > runtimepath is modified based on the __file__ variable, but this is > the responsibility of plugin. So we support it this way. So we should create a sample plugin later. How to "backport" your stuff to older Vim? That's why I think that creating viml code is a better option for the beginning. What about introducing &pip_install_expr ? let g:pip_install_expr=pip#Install(v:package, true) where true means "want confirmation". Then user can easily replace the implementation. And you can get rid of allmost all options you've been talking about. And everybody can replace it easily by providing his own implementation if required. I think its much more flexible than having things built into Vim. Also what you built into Vim should be supported forever .. Using VimL means you can also support older vim installations easily. > Not in any case. Unless you take the pip sources and modify them to > include something like --ask switch (this is why I added a note that > `:pyload` will use regular `!`). I'm not against it. But I guess people want to know what is happening. Would you join a viml only implementation to get started with this all? Its also going to take less time than a Vim patch. > > - should it be possible that one plugin requires another one / two > > plugins require each other? > Python-only plugins are not supposed to depend on vim ones. I'd expect users thinking in objects of "this gets that feature done" not caring about those solutions being viml or python. The user should not care IMHO. > dependencies are specified in the setup.py as usual. Main idea is that > python already has a package manager thus we don't want to invent > another one. If we do - then let's have both: PIP and Vam/Vundle/etc But allow PIP to replace VAM. We should setup mirroring anyway. Who wants to unpack .tar.gz on Windows !? But thats another (future) story. Npackd like implementations would also benefit. Think about why this must be Vim patch. I think we can get reasonably close by just providing a autload/ file. 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.
