On Jun 5, 2013 1:22 AM, "Marc Weber" <[email protected]> wrote: > > 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.
He makes: when does (not) specify bang. > > > - 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. ***! **IT DOES NOT RUN PIP.** By the time pip **HAD *ALREADY* DONE** all the necessary job. > > 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. Just take my pseudo-code from RFC with some minor modifications and a VimL wrapper. Except that you will have to use globals in place of options. > 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 was talking about only one option. > I think its much more flexible than having things built into Vim. > Also what you built into Vim should be supported forever .. This is the intention. Not building something into vim leads to creating bicycles by plugin authors. And I never saw anybody using functions defined in vim runtime files (except for vimball support in VAM). There must be a reason for it. > 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. It is not possible and not required. For python+viml implementation take code from RFC, replace exec and supply a wrapper. > > > - 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. There is no standard plugin manager for VimL and none at all that may specify python dependencies. And it is not user who needs to care, it is developer. I bet depending on viml plugins will not be popular at all, so no need to care. > > 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. Wondering how do you imagine this. And what this note is for: if you wish, you can already use VAM, Vundle and system package manager at a time. As far as they all manage different plugins it is fine. > 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. > > -- -- 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.
