On Fri, Nov 21, 2008 at 10:00:04AM -0500, Charles Campbell wrote: > > Tom Link wrote: > >> a#b#version0_1#foo() ? > >> Yes, using old windows style currently then. But you have to choose the location to save the files (like g:vimball_home ?).
However it's not a question about vimball, but a question about how to identify a function Foo of lib version 1 or 2. So I don't see how vimball can protect against that? Example: bundle 1: fun a#Foo() " version1 enfun bundle 2: fun a#Foo() " version2 enfun So which function is used when running call a#Foo()? That depends on your runtimepath settings. The only way to protect against that is using bundle 1: fun a#V1#Foo() " version1 enfun bundle 2: fun a#V2#Foo() " version2 enfun and call a#V1#Foo() or a#V2#Foo() But that is totally independant of the installer system. So this is the only way to go. But even then the meaning of global vars might change. So We must add verion information as well.. I agree that the way vimball does add the files is better by adding line counts. You're right. It shouldn't be much work to ask my dependency analysis system create .vba files. > > and foo. If you wanted to update foo, you wouldn't have to touch > > packages A and B. Then you still don't have any guarantee that it works, see above. >Tom wrote >BTW I took the liberty to re-implement your outline.vim in ttoc[1], >which does some dynamic filtering. > [1] http://www.vim.org/scripts/script.php?script_id=2014 Tom! Awesome! Thanks for pointing me to it.. Would you like to join our effort by adding this script in the near future after figuring out which is the best way mantain a global vim library ? Also see my next post Marc --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
