Hi Tom, On Fri, Feb 06, at 10:56 Tom Link wrote: > > > So for a start, I am proposing a "VimLib" project, maintainable by the Vim > > community, written entirely in VimL and except from one function (see > > below) it will independent from the vim official distribution. > > > It's based on personal experiments and from the work > > of Marc Weber and Luc Hermitte. > > How does your proposal differ from Marc Weber's approach[1] that is > IIRC meant as a community project too. > > [1] http://github.com/MarcWeber/theonevimlib/tree/master >
It doesn't differ. In fact I am waiting from Marc or Luc to lead the project. Let me explain. We are talking about two different issues/things but with direct connection to each other. a. Reusable and efficient code. A stable API that it's main purpose will be first to avoid duplicate code and then to provide efficient and maintainable code to developers and users. b. Plugin management. A similar concept with cpan, luarocks, rubygems, etc... While the first is self explained (it's plain code), the second is intended to be the glue between the library, the developer and the end user. So I realize that some more expansion is needed. The developer doesn't has to care how will package his work, or doesn't has to care if the requested function for his tool is available or not to the user's machine. This is usually a job for the specialized tools like the ones I mentioned above. If they are absent, a number of problems can be arise. To give an example. Think how the autotools work in Unix like systems. During initial configuration (when you run ./configure) if a library that is a prerequisite for the tool to work is not available the configure script raises an error. Distributions (Linuxes and Bsds) solve this problem using package management techniques to ensure that the toolchain will be sane and the binaries will work the way it was intended. Depending from the nature or the maturity of the distribution this can be sometimes a really complex stuff like in the following: package foo wants the libraryfoo.5.so while other packages wants libraryfoo.6.so. For this particular case, however - speaking for vim - there is an advance, just because the way the autoload mechanism works, but still work needs to be done to ensure that the right function is going to be used. That's why a testing framework is most welcomed and absolutely necessary. And thats why a *design* and a *set of predefined rules* are needed. And this my answer to your question and why I raised the discussion. But, just to continue a bit about this subject, which and to be honest, I am a little sensitive about, since I am building my own distribution following the guides in the linuxfromscratch.org, and because is a domain I like to work. (I've uploaded a quite recent work - just to take an idea - which is based completely in VimL and standard tools and curl. http://www.linuxfromscratch.org/~ag/vpkgman/ Note: this is unfinished work; I want to add functions to extract more information and other features I have in mind, but which is not the right forum to discuss. So, what I am thinking about is a system based on spec files that will store in dictionaries, all the needed information, so a script can be installed properly and automatically with all its dependencies, using standard provided routines. Again if a design will be decided then the code is easy. In that domain I can contribute my free hours - though my wife and my four children (and some animals) might disagree. :) And one last thing. I am not sure if a new system is really needed and I really don't want to push things in life. But if there is a general agreement, then this has to be a community project, because as I like to say: "While a single person can *change* the world, she can't *save* the world." Regards, Ag. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
