Plugin manager with dependencies and selective bundle load
103 views
Skip to first unread message
Pablo Giménez
Apr 23, 2012, 11:51:08 AM4/23/12
to vim_use
Hi all.
I am testing different plugin managers for vim.
I have been playing with pathogen and tplugin (http://www.vim.org/scripts/script.php?script_id=2917)
I begun with pathogen, and seems everybody is following the idea of bundles, which I think is good.
But soon I found some limitations with this tool. Seems there is no way to control the order of loading for the plugins, and there are not dependencies.
It also tens to create a massive runtime path when sometimes is not needed.
So I then found tplugin.
I love how fast vim loads using tplugin and how it changes the runtime path on demand.
But then I also found some limitations. Seems thare is no way to tell the tool not to load some plugins, also the dependency system looks a little but clunky because it is based on files rather than bundles.
In many situations using files is all right, but for me makes sense to have the option to use bundles rather than a file pattern to trigger dependencies.
In my case one of the reasons because I want to use dependencies and to control what to load is because I want to have all my plugins in a bundle folder, but most of the time I dont want to use the public interface, so I just made a kind of a wrapper bundle, they simlinks the autoload folder to the original plugin and I copy the scripts in plugin and change the public interface to adapt it to my needs.
Like fir instance, the key maps, entries in the menu, etc ... These are the kind of things I usually want to override.
So I will love to be able to have a kind of master bundle, which loads all the dependencies, other bundles, and for the bundles that needs a wrapper, I want to load the wrapper and not the original pluging.
For instance imagine I have the next bundles in my plugins folder:
base
ZoomWin
myZoomWin
base will load myZoomWin as a depency and myZoomWin will reuse all the private stuff from ZoomWin plugin (mostly the scripts in the autoload folder), but will change the keymaps and commands definitions done in ZoomWin/pluging/ZoomWinPlugin.vim.
I am pretty sure there are different ways to manage this, also I am probably missing something with the two tools I have tested so far, and probably there is a way to do what I want either using pathogen or tplugin.
Or there are better tools out there to manage plugins that can do what I am looking for.
Any advice here is very welcome.
Thanks.
--
Un saludo
Best Regards
Pablo Giménez
I am testing different plugin managers for vim.
I have been playing with pathogen and tplugin (http://www.vim.org/scripts/script.php?script_id=2917)
I begun with pathogen, and seems everybody is following the idea of bundles, which I think is good.
But soon I found some limitations with this tool. Seems there is no way to control the order of loading for the plugins, and there are not dependencies.
It also tens to create a massive runtime path when sometimes is not needed.
So I then found tplugin.
I love how fast vim loads using tplugin and how it changes the runtime path on demand.
But then I also found some limitations. Seems thare is no way to tell the tool not to load some plugins, also the dependency system looks a little but clunky because it is based on files rather than bundles.
In many situations using files is all right, but for me makes sense to have the option to use bundles rather than a file pattern to trigger dependencies.
In my case one of the reasons because I want to use dependencies and to control what to load is because I want to have all my plugins in a bundle folder, but most of the time I dont want to use the public interface, so I just made a kind of a wrapper bundle, they simlinks the autoload folder to the original plugin and I copy the scripts in plugin and change the public interface to adapt it to my needs.
Like fir instance, the key maps, entries in the menu, etc ... These are the kind of things I usually want to override.
So I will love to be able to have a kind of master bundle, which loads all the dependencies, other bundles, and for the bundles that needs a wrapper, I want to load the wrapper and not the original pluging.
For instance imagine I have the next bundles in my plugins folder:
base
ZoomWin
myZoomWin
base will load myZoomWin as a depency and myZoomWin will reuse all the private stuff from ZoomWin plugin (mostly the scripts in the autoload folder), but will change the keymaps and commands definitions done in ZoomWin/pluging/ZoomWinPlugin.vim.
I am pretty sure there are different ways to manage this, also I am probably missing something with the two tools I have tested so far, and probably there is a way to do what I want either using pathogen or tplugin.
Or there are better tools out there to manage plugins that can do what I am looking for.
Any advice here is very welcome.
Thanks.
--
Un saludo
Best Regards
Pablo Giménez
Marc Weber
Apr 23, 2012, 12:26:06 PM4/23/12
to vim_use
You missed github.com/MarcWeber/vim-addon-manager which adds these
features:
+ maintained pool of packages (you can opt-out or provide your own
one)
+ automatic loading of dependency, they are listed in a
addon-info.json file
+ loading plugins at runtime (if supported by the plugin)
+ supports many VCS systems: git,svn,hg,...
This implies that git submodules are no longer used
+ it gets almost all directory layouts right because the pool is
maintained and the pool contains some correcting code for those
plugins.
features:
+ maintained pool of packages (you can opt-out or provide your own
one)
+ automatic loading of dependency, they are listed in a
addon-info.json file
+ loading plugins at runtime (if supported by the plugin)
+ supports many VCS systems: git,svn,hg,...
This implies that git submodules are no longer used
+ it gets almost all directory layouts right because the pool is
maintained and the pool contains some correcting code for those
plugins.
issues with vim-addon-manager: because you don't have git submodules
reinstalling will always fetch latest versions always - which has not
been a problem yet - but could be a risk.
Order of loading should be preserved beacuse you list names of the
plugins to be activated in your .vimrc
You also missed vundle (which is similar to pathogen, a nice simple
solution if you want to install github based plugins only)
There is also vimana, ruby scripts installing addons.
And there is plain old :h GetLatestVimScripts which only gets updates
from www.vim.org (AFAIK).
Which is best? I don't know. I wrote vim-addon-manager because I want to
serve the community: I want them to notice if they use an old upstream -
and I was looking for a way to distribute my own code without copy
pasting or writing dozens of lines about how to install each one and
where to get dependencies. In most cases this is a warning you can
ignore and still get whatever you want.
future:
I'd like to move some of the information found in
vim-addon-manager-know-repository to the official website (such as
deprecation warnings or hinting that alternative plugins may serve you
better for whatever reason)
I dream about replacing www.vim.org by a simple "enter your github,
bitbucket, .." url and be done. www.vim.org should poll for updates etc.
I just haven't had time to implement a prototype yet.
HTH
Marc Weber
Pablo Giménez
Apr 25, 2012, 1:08:49 PM4/25/12
to vim...@googlegroups.com
I have been playing around with vim addon manager.
I think it is really good, but not sure it suits all my needs.
For the runtime path, it is good you can set it manually using ActiveAddon.
But I think is not possible to load the plugins on demand, like in tplugin, which is a feature I really love.
Another doubt I have is, if I have a plugin/bundle, which hasnt been installed by VAM, it is possible to activate it?
for instance imagine in the VAM install folder I have a folder with the name myPlugin.
Which is a plugin I am developing, it is yet not under control by any CVS. I just want to load it as any other addon.
So if I make:
ActivateAddons myPlugin
I got the next error:
No repository location info known for plugin myPlugin.
Finally vim crashes almost after any add on install.
Wondering if it is because of the version of git we have here. Dont know.
Thanks.
2012/4/23 Marc Weber <marco-...@gmx.de>
I think it is really good, but not sure it suits all my needs.
For the runtime path, it is good you can set it manually using ActiveAddon.
But I think is not possible to load the plugins on demand, like in tplugin, which is a feature I really love.
Another doubt I have is, if I have a plugin/bundle, which hasnt been installed by VAM, it is possible to activate it?
for instance imagine in the VAM install folder I have a folder with the name myPlugin.
Which is a plugin I am developing, it is yet not under control by any CVS. I just want to load it as any other addon.
So if I make:
ActivateAddons myPlugin
I got the next error:
No repository location info known for plugin myPlugin.
Finally vim crashes almost after any add on install.
Wondering if it is because of the version of git we have here. Dont know.
Thanks.
2012/4/23 Marc Weber <marco-...@gmx.de>
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
Marc Weber
Apr 25, 2012, 3:15:13 PM4/25/12
to vim_use
> But I think is not possible to load the plugins on demand, like in tplugin,
Why do you think so? If the author tells you it is possible if the
plugin supports it then you should give a reason.
Those who don't are those plugins who are using Start auto commands.
And there is not much you can do about it but a *lot* of patching.
> Another doubt I have is, if I have a plugin/bundle, which hasnt been
> installed by VAM, it is possible to activate it?
" unless those directories exist. Then they are activated.
This sentence in the SetupVAM function was written to reply to exactly
that question. If you have any idea how to improve the wording let me
know.
echo "echoe 'abc'" >> ~/.vim/vim-addons/abc/plugin/any-name.vim
Then start vim and do :ActivateAddon abc
You'll get the error message.
So I'm pretty sure that you've missed a small detail :)
Just recheck and retry
> Finally vim crashes almost after any add on install.
I want fix some segfaults my self. in the end its not VAM's fault - Vim
should not crash if using VimL only.
Just write again if you have additional / still the same problems.
Yours
Marc Weber
Pablo Giménez
Apr 26, 2012, 2:00:23 PM4/26/12
to vim...@googlegroups.com
2012/4/25 Marc Weber <marco-...@gmx.de>
> But I think is not possible to load the plugins on demand, like in tplugin,Why do you think so? If the author tells you it is possible if the
plugin supports it then you should give a reason.
Those who don't are those plugins who are using Start auto commands.
And there is not much you can do about it but a *lot* of patching.
I am not talking about putting all the stuff in autoload. Which a task for he plugin developer.
tplugin scans all the bundles and then use the VimEnter event to load them on the fly. (I think, is what I understand from the docs)
So the initial runtime path is very short, but as soon as you call to a function in the autoload of a plugin it is added to the runtime path and loaded.
I dont know exactly how it works but this is what it is doing ans is great.
AFAIK in vam you have to activate the plugins manually using ActivateAddons, then the plugin rather than being waiting to be called it is loaded.
This is what I mean about loading on demand.
I am probably missing something and vam can do the same thing.
It is similar to the experimental mechanism to load plugins based on filetypes I have seen in the vam docs, but for functions in autoload and if it is possible for commands.
As soon as you use an autoload function or a command defined by a plugin it is loaded in the runtime path.
tplugin scans all the bundles and then use the VimEnter event to load them on the fly. (I think, is what I understand from the docs)
So the initial runtime path is very short, but as soon as you call to a function in the autoload of a plugin it is added to the runtime path and loaded.
I dont know exactly how it works but this is what it is doing ans is great.
AFAIK in vam you have to activate the plugins manually using ActivateAddons, then the plugin rather than being waiting to be called it is loaded.
This is what I mean about loading on demand.
I am probably missing something and vam can do the same thing.
It is similar to the experimental mechanism to load plugins based on filetypes I have seen in the vam docs, but for functions in autoload and if it is possible for commands.
As soon as you use an autoload function or a command defined by a plugin it is loaded in the runtime path.
" Addons are put into vam_install_path/plugin-name directory
> Another doubt I have is, if I have a plugin/bundle, which hasnt been
> installed by VAM, it is possible to activate it?
" unless those directories exist. Then they are activated.
Yep sorry my bad I got this working.
This sentence in the SetupVAM function was written to reply to exactly
that question. If you have any idea how to improve the wording let me
know.
echo "echoe 'abc'" >> ~/.vim/vim-addons/abc/plugin/any-name.vim
Then start vim and do :ActivateAddon abc
You'll get the error message.
So I'm pretty sure that you've missed a small detail :)
Just recheck and retry
Update to latest Vim version. Sorry about that.
> Finally vim crashes almost after any add on install.
No problem I think we have vim 7.3 installed also, but is not the default version here.
Ill try 7.3 and see if it solves the instability.
Ill try 7.3 and see if it solves the instability.
I want fix some segfaults my self. in the end its not VAM's fault - Vim
should not crash if using VimL only.
Just write again if you have additional / still the same problems.
I have been trying dependencies.
So I created the addon-info.json file inside my plugin root.
It works fine but seems dependencies works for installing plugins, not for loading.
So if I have:
plugin1
plugin2
And plugin1 depends on plugin2, if I install plugin1 vam ask me to install plugin2, which is great.
What I am looking for is also the same thing but for activate plugins, so if I do:
ActivateAddon plugin1
plugin2 is automatically activated, I dont want to do:
ActivateAddon plugin2
ActivateAddon plugin1
Is there any way to achieve this in vam?
Thanks!
So I created the addon-info.json file inside my plugin root.
It works fine but seems dependencies works for installing plugins, not for loading.
So if I have:
plugin1
plugin2
And plugin1 depends on plugin2, if I install plugin1 vam ask me to install plugin2, which is great.
What I am looking for is also the same thing but for activate plugins, so if I do:
ActivateAddon plugin1
plugin2 is automatically activated, I dont want to do:
ActivateAddon plugin2
ActivateAddon plugin1
Is there any way to achieve this in vam?
Thanks!
Yours
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
lith
Apr 27, 2012, 12:38:16 AM4/27/12
to vim...@googlegroups.com
Hi,
> I love how fast vim loads using tplugin and how it changes the runtime path on demand.
> But then I also found some limitations. Seems thare is no way to tell the tool not to load some plugins, also the dependency system looks a little but clunky because it is based on files rather than bundles.
I'm not sure what you mean by "not loading plugins". Since version 0.14, you can define "shallow" root directories. Plugins in such a directory can be loaded by means of the :TPlugin command but shouldn't be automatically loaded if you call one if its commands or functions etc.
Dependency handling can admittedly be improved. tplugin knows three ways of handling dependencies:
(1) Don't handle dependencies and load plugins as needed (this won't work if a plugin tests if another plugin was already loaded by checking the existence of a variable)
(2) Check if a plugins checks for the existence of loaded_PLUGIN_NAME (this requires that the plugin authors adhered to the formatting rules which they probably didn't :-)
(3) Use the info in *-addon-info.txt files if the plugin provides one.
If the above fails, you can define a file _tplugin_PLUGIN_NAME.vim to define dependencies like:
call TPluginDependencies('THIS_PLUGIN', ['OTHER_PLUGIN'])
I guess you could put this definitions also into vimrc.
HTH
Tom
Marc Weber
Apr 27, 2012, 8:13:34 AM4/27/12
to vim_use
Excerpts from Pablo Giménez's message of Thu Apr 26 20:00:23 +0200 2012:
used.
You're right, VAM does not support such yet.
Feel free to use VAM to :InstallAddons only and use tplugin for
activating them.
My understanding of pludins is:
plugin/*.vim: everything the user can customize (settings, interface,
mappings, commansds)
autoload/*: everything else
VAM has an experimental function to "merge" all plugin/* files so that
only one file is sources - but this still assumes that plugins only put
minimal configuration into the plugin files - and the if .. finish line
may be causing trouble easily and such.
Due to commands I personally assume that plugin files should always be
read - you're right, you can replace commansds/ mappings by "fake"
implementations activating a plugin first.
Before you make me spend time on such do profiling and tell me what's
causing most trouble to you.
> Yep sorry my bad I got this working.
You're welcome. Its easy to miss a detail if there is so much new stuff.
plugin2 depending on plugin1 and auto activation:
Retry again. This would be a serious bug.
If can't make it work I can invite you to a SSH session so that you can
proof me that its behaving wrong easily.
Marc Weber
> I dont know exactly how it works but this is what it is doing ans is great.
> AFAIK in vam you have to activate the plugins manually using
> ActivateAddons, then the plugin rather than being waiting to be called it
> is loaded.
There is a 'func not defined' hook which can be used. Maybe that is
> AFAIK in vam you have to activate the plugins manually using
> ActivateAddons, then the plugin rather than being waiting to be called it
> is loaded.
used.
You're right, VAM does not support such yet.
Feel free to use VAM to :InstallAddons only and use tplugin for
activating them.
My understanding of pludins is:
plugin/*.vim: everything the user can customize (settings, interface,
mappings, commansds)
autoload/*: everything else
VAM has an experimental function to "merge" all plugin/* files so that
only one file is sources - but this still assumes that plugins only put
minimal configuration into the plugin files - and the if .. finish line
may be causing trouble easily and such.
Due to commands I personally assume that plugin files should always be
read - you're right, you can replace commansds/ mappings by "fake"
implementations activating a plugin first.
Before you make me spend time on such do profiling and tell me what's
causing most trouble to you.
> Yep sorry my bad I got this working.
plugin2 depending on plugin1 and auto activation:
Retry again. This would be a serious bug.
If can't make it work I can invite you to a SSH session so that you can
proof me that its behaving wrong easily.
Marc Weber
Pablo Giménez
Apr 27, 2012, 1:38:32 PM4/27/12
to vim...@googlegroups.com
Hi,
I'm not sure what you mean by "not loading plugins". Since version 0.14, you can define "shallow" root directories. Plugins in such a directory can be loaded by means of the :TPlugin command but shouldn't be automatically loaded if you call one if its commands or functions etc.
> I love how fast vim loads using tplugin and how it changes the runtime path on demand.
> But then I also found some limitations. Seems thare is no way to tell the tool not to load some plugins, also the dependency system looks a little but clunky because it is based on files rather than bundles.
Cool I have missed this feature from the docs.
Dependency handling can admittedly be improved. tplugin knows three ways of handling dependencies:
(1) Don't handle dependencies and load plugins as needed (this won't work if a plugin tests if another plugin was already loaded by checking the existence of a variable)
(2) Check if a plugins checks for the existence of loaded_PLUGIN_NAME (this requires that the plugin authors adhered to the formatting rules which they probably didn't :-)
How can I use this?
I understand TPluginDependencies only accepts file name patterns, no plugin names. at least is what the docs says.
I understand TPluginDependencies only accepts file name patterns, no plugin names. at least is what the docs says.
(3) Use the info in *-addon-info.txt files if the plugin provides one.
Mmmm is this the same file used by vim-addon-manager?
If the above fails, you can define a file _tplugin_PLUGIN_NAME.vim to define dependencies like:
call TPluginDependencies('THIS_PLUGIN', ['OTHER_PLUGIN'])
Ok so TPluginDependencies( accepts plugins names isnt it?
I guess you could put this definitions also into vimrc.
HTH
Tom
--
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
Pablo Giménez
Apr 27, 2012, 1:42:11 PM4/27/12
to vim...@googlegroups.com
Excerpts from Pablo Giménez's message of Thu Apr 26 20:00:23 +0200 2012:
> I dont know exactly how it works but this is what it is doing ans is great.There is a 'func not defined' hook which can be used. Maybe that is
> AFAIK in vam you have to activate the plugins manually using
> ActivateAddons, then the plugin rather than being waiting to be called it
> is loaded.
used.
You're right, VAM does not support such yet.
Feel free to use VAM to :InstallAddons only and use tplugin for
activating them.
Yep I think I am going to try this route .
My understanding of pludins is:
plugin/*.vim: everything the user can customize (settings, interface,
mappings, commansds)
autoload/*: everything else
This is also what I think about how to develop plugins, problem arise if you want to override all the public interface, like commands or keymaps for your own ones and mainly use what is uner autoload.
VAM has an experimental function to "merge" all plugin/* files so that
only one file is sources - but this still assumes that plugins only put
minimal configuration into the plugin files - and the if .. finish line
may be causing trouble easily and such.
Due to commands I personally assume that plugin files should always be
read - you're right, you can replace commansds/ mappings by "fake"
implementations activating a plugin first.
Before you make me spend time on such do profiling and tell me what's
causing most trouble to you.
You're welcome. Its easy to miss a detail if there is so much new stuff.
> Yep sorry my bad I got this working.
plugin2 depending on plugin1 and auto activation:
Retry again. This would be a serious bug.
Auto activation, Ill look into the dos for this, I dont know about the autoactivation feature.
If can't make it work I can invite you to a SSH session so that you can
proof me that its behaving wrong easily.
Marc Weber
Thanks!
--
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
Charles Campbell
Apr 27, 2012, 2:01:20 PM4/27/12
to vim...@googlegroups.com
Marc Weber wrote:
> Excerpts from Pablo Gim�nez's message of Thu Apr 26 20:00:23 +0200 2012:
totally different issue, and is often done by setting variables in .vimrc.
> autoload/*: everything else
>
autoload/*.vim holds scripts that will be loaded on demand; ie. when a
mapping or command in a plugin/something.vim script attempts to call a
function of the form
something#AFunction(), then autoload/something.vim will be loaded and
then the function call performed. This process does require that the
plugins be written/changed to accomodate this style.
That's why I wrote AsNeeded -- it introduces a new folder (AsNeeded/, of
course), wherein scripts reside that are not particularly written for
the autoload method. It makes a pass through scripts in that directory
and builds a single file, ANcmds.vim, that contain just enough to
support commands, sourcing the AsNeeded/function.vim scripts on demand.
It doesn't support building maps that way, though. There's a command
":AN somefile.vim" that will source an AsNeeded script, too.
Regards,
Chip Campbell
> Excerpts from Pablo Gim�nez's message of Thu Apr 26 20:00:23 +0200 2012:
>
>> I dont know exactly how it works but this is what it is doing ans is great.
>> AFAIK in vam you have to activate the plugins manually using
>> ActivateAddons, then the plugin rather than being waiting to be called it
>> is loaded.
>>
> There is a 'func not defined' hook which can be used. Maybe that is
> used.
> You're right, VAM does not support such yet.
> Feel free to use VAM to :InstallAddons only and use tplugin for
> activating them.
>
> My understanding of pludins is:
>
> plugin/*.vim: everything the user can customize (settings, interface,
> mappings, commansds)
>
plugin/*.vim holds scripts that will be loaded. Customization is a
>> I dont know exactly how it works but this is what it is doing ans is great.
>> AFAIK in vam you have to activate the plugins manually using
>> ActivateAddons, then the plugin rather than being waiting to be called it
>> is loaded.
>>
> There is a 'func not defined' hook which can be used. Maybe that is
> used.
> You're right, VAM does not support such yet.
> Feel free to use VAM to :InstallAddons only and use tplugin for
> activating them.
>
> My understanding of pludins is:
>
> plugin/*.vim: everything the user can customize (settings, interface,
> mappings, commansds)
>
totally different issue, and is often done by setting variables in .vimrc.
> autoload/*: everything else
>
autoload/*.vim holds scripts that will be loaded on demand; ie. when a
mapping or command in a plugin/something.vim script attempts to call a
function of the form
something#AFunction(), then autoload/something.vim will be loaded and
then the function call performed. This process does require that the
plugins be written/changed to accomodate this style.
That's why I wrote AsNeeded -- it introduces a new folder (AsNeeded/, of
course), wherein scripts reside that are not particularly written for
the autoload method. It makes a pass through scripts in that directory
and builds a single file, ANcmds.vim, that contain just enough to
support commands, sourcing the AsNeeded/function.vim scripts on demand.
It doesn't support building maps that way, though. There's a command
":AN somefile.vim" that will source an AsNeeded script, too.
Regards,
Chip Campbell
Pablo Giménez
May 10, 2012, 7:40:04 AM5/10/12
to vim...@googlegroups.com
2012/4/27 Marc Weber <marco-...@gmx.de>
Excerpts from Pablo Giménez's message of Thu Apr 26 20:00:23 +0200 2012:
> I dont know exactly how it works but this is what it is doing ans is great.There is a 'func not defined' hook which can be used. Maybe that is
> AFAIK in vam you have to activate the plugins manually using
> ActivateAddons, then the plugin rather than being waiting to be called it
> is loaded.
used.
You're right, VAM does not support such yet.
Feel free to use VAM to :InstallAddons only and use tplugin for
activating them.
Finally I follow your indications I am using only VAM.
The difference using tplugin is minimal, and tplugin at the end looks like a hack, like the AsNeeded plugin.
All loading on demand should be done using te autoload feature ans you and Campbell pointed.
So is more a responsability of the plugin developer.
Luckely most plugins nowdays use have the private interface in autoload.
I am also using the experimental activation of add ons using filetype, seems to be working fine.
One thing related to this feature is that if you want to make a plugin depend on another, but only load when a certain filetype is set, is impossible I think.
For instance if pluginB depends on pluginA. And you want to pluginA only for certain filetypes.
As soon as you put pluginA in the addon-info.json for pluginB as a dependency it will be activated when pluginB is activated.
Is there any way to set the dependency, mainly for installing pourposes, but only get it activated when a certain filetype is set?
Thanks
The difference using tplugin is minimal, and tplugin at the end looks like a hack, like the AsNeeded plugin.
All loading on demand should be done using te autoload feature ans you and Campbell pointed.
So is more a responsability of the plugin developer.
Luckely most plugins nowdays use have the private interface in autoload.
I am also using the experimental activation of add ons using filetype, seems to be working fine.
One thing related to this feature is that if you want to make a plugin depend on another, but only load when a certain filetype is set, is impossible I think.
For instance if pluginB depends on pluginA. And you want to pluginA only for certain filetypes.
As soon as you put pluginA in the addon-info.json for pluginB as a dependency it will be activated when pluginB is activated.
Is there any way to set the dependency, mainly for installing pourposes, but only get it activated when a certain filetype is set?
Thanks
My understanding of pludins is:
plugin/*.vim: everything the user can customize (settings, interface,
mappings, commansds)
autoload/*: everything else
VAM has an experimental function to "merge" all plugin/* files so that
only one file is sources - but this still assumes that plugins only put
minimal configuration into the plugin files - and the if .. finish line
may be causing trouble easily and such.
Due to commands I personally assume that plugin files should always be
read - you're right, you can replace commansds/ mappings by "fake"
implementations activating a plugin first.
Before you make me spend time on such do profiling and tell me what's
causing most trouble to you.
You're welcome. Its easy to miss a detail if there is so much new stuff.
> Yep sorry my bad I got this working.
plugin2 depending on plugin1 and auto activation:
Retry again. This would be a serious bug.
If can't make it work I can invite you to a SSH session so that you can
proof me that its behaving wrong easily.
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
Marc Weber
May 10, 2012, 8:13:40 AM5/10/12
to vim_use
Well - you can add call vam#ActivateAddon([...]) to any logic you like -
however then the plugins are likely to depend on VAM which may not what
you want. Of course you can do so conditionally if the function exist.
Something roughly like this:
augroup AU_NAME
autocmd BufRead,BufNewFile *.py call ActivateAddon([foo])
autocmd BufRead,BufNewFile *.php call ActivateAddon([foo, bar])
augroup end
now bar only get's loaded if you edit php files.
Think about how many ms you're going to safe by spending such
huge amounts of time ..
Marc Weber
however then the plugins are likely to depend on VAM which may not what
you want. Of course you can do so conditionally if the function exist.
Something roughly like this:
augroup AU_NAME
autocmd BufRead,BufNewFile *.py call ActivateAddon([foo])
autocmd BufRead,BufNewFile *.php call ActivateAddon([foo, bar])
augroup end
now bar only get's loaded if you edit php files.
Think about how many ms you're going to safe by spending such
huge amounts of time ..
Marc Weber
Pablo Giménez
May 11, 2012, 3:32:08 PM5/11/12
to vim...@googlegroups.com
2012/5/10 Marc Weber <marco-...@gmx.de>
Thanks Marc.
In this case is not a matter of saving time.
I want to create a dependancy, setting it in the addon-info file, so when I install the plugin the dependancy will be installed as well.
But for activating the plugin I want to do it basd on a file type.
Now when you have a dependancy, it affects installation and also activation of the plugin.
Someyhing like conditional dependancy would be great, so for instance if tis condition isa file type, the plugin will be downloaded but not activated, it only will be activatedif the file type is true for the condition.
In this case is not a matter of saving time.
I want to create a dependancy, setting it in the addon-info file, so when I install the plugin the dependancy will be installed as well.
But for activating the plugin I want to do it basd on a file type.
Now when you have a dependancy, it affects installation and also activation of the plugin.
Someyhing like conditional dependancy would be great, so for instance if tis condition isa file type, the plugin will be downloaded but not activated, it only will be activatedif the file type is true for the condition.
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
Marc Weber
May 11, 2012, 3:40:58 PM5/11/12
to vim_use
Activating a plugin does not cause much overhead , only a path to
&runtimepath is added unless the plugin also has plugin/*.vim files.
So make me understand what's wrong with always activating the plugin?
Why is it that costly that you want to avoid it?
Of course adding 'dependencies-to-be-installed-only' is no issue.
However I'd like to avoid complexity if possible.
We may end up creating a github issue before taking any actions so that
all people involed (eg ZyX) can think about it.
Marc Weber
&runtimepath is added unless the plugin also has plugin/*.vim files.
So make me understand what's wrong with always activating the plugin?
Why is it that costly that you want to avoid it?
Of course adding 'dependencies-to-be-installed-only' is no issue.
However I'd like to avoid complexity if possible.
We may end up creating a github issue before taking any actions so that
all people involed (eg ZyX) can think about it.
Marc Weber
Pablo Giménez
May 14, 2012, 6:25:42 AM5/14/12
to vim...@googlegroups.com
2012/5/11 Marc Weber <marco-...@gmx.de>
Activating a plugin does not cause much overhead , only a path to
&runtimepath is added unless the plugin also has plugin/*.vim files.
Yep I know, just thinking ahead if having a big runtimepath can make things slower.
So make me understand what's wrong with always activating the plugin?
Why is it that costly that you want to avoid it?
Of course adding 'dependencies-to-be-installed-only' is no issue.
However I'd like to avoid complexity if possible.
I think if the "Activation on file Type" mechanism get more stable and finally is included in VAM out of the box, this feature, dependencies only for installation makes sense.
We may end up creating a github issue before taking any actions so that
all people involed (eg ZyX) can think about it.
No p[roblem is you think is the bst way to report the issue.
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
Marc Weber
May 14, 2012, 8:58:44 AM5/14/12
to vim_use
Excerpts from Pablo Giménez's message of Mon May 14 12:25:42 +0200 2012:
runtimepaths into a .vim/ so that you can benchmark the difference and
whether it matters.
Currently I'd rather rewrite the homepage than implementing such things
for VAM because VAM already does a great job IMHO.
It does not here - and the true fix is likely to replace VimL by JS or
another jitted scripting language (IMHO). But that's only my point of
view.
Also if you really want to speed up your work flows get an SSD :)
Yours
Marc Weber
> Yep I know, just thinking ahead if having a big runtimepath can make things
> slower.
You're right. I'm fine with writing experimental code merging all
> slower.
runtimepaths into a .vim/ so that you can benchmark the difference and
whether it matters.
Currently I'd rather rewrite the homepage than implementing such things
for VAM because VAM already does a great job IMHO.
It does not here - and the true fix is likely to replace VimL by JS or
another jitted scripting language (IMHO). But that's only my point of
view.
Also if you really want to speed up your work flows get an SSD :)
Yours
Marc Weber
Reply all
Reply to author
Forward
0 new messages