Hi John,
On Fri, Feb 06, at 10:44 John Beckett wrote:
>
> Garrett Whelan wrote:
> > 3) Is there a central repository of vim scripts/extentions?
> > It seems rather haphazard to me. I often find 4-5 scripts
> > that solve my problem with little documentation for any and
> > none of them have been updated for years.
>
> www.vim.org and click scripts is the central repository. Yes, it is
> haphazard. Ideally a team of 10 full time experts would weed out 95% of
> the scripts (delete them), and enhance the remaining 5%.
An exaggeration (in my opinion) but again not far from the truth.
But this is a quite interesting topic, and is a problem that (we) will
face it and (we) will have to deal with it, soon or later.
Some facts:
- (most) plugins don't take advantage of the 'autoload' mechanism
- (many) plugins overlap functionality with others
- too much evaporated code or functions that solve same or similar
problems (few plugins share some code)
- no bug tracker or no mailing list, so no review, no feedback and no
bug tracking
- no revision control so no logs and history
- pure categorization
- unmaintainable or poor quality plugins
It seems that we have two paths that we can take:
a. Enhance, fix and reorganize the existing infrastructure.
b. Start from the scratch
That pretty much leave us with just one option, because I don't think that
there is someone with sane mind that will volunteer to take the lonely
first path. Besides that, a scratch project is always refreshing and almost
guaranteed to give energy (Note: this is not an excuse to leave your
marriage!).
So here are some thoughts:
The whole (new) system should (should as in http://www.ietf.org/rfc/rfc2119.txt
)
be based in the 'autoload' mechanism. The main advantages of the autoload
functions are:
- fast vim startup
- less memory consumed, since they just loaded when you really need
them (when you call them via a mapping, a command or another function)
- the directory and file/plugin structure can be organized with
absolutely no limits
- it's perfect for sharing code between the various implementations
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.
The purpose of this project is to create stable functions to return values
or to execute actions.
A sample directory structure could be:
autoload/lib
autoload/util
autoload/buffer
autoload/cmdline
autoload/time
...
Sample functions/scripts:
autoload/lib/filelist
autoload/util/scratch
autoload/buffer/bufferlist
autoload/cmdline/removelastpathcomponent
autoload/time/weekday
...
A developer that wants to utilize such a function, should include on the
top of the implementation, a standard code block to request the function.
If it's not available then a similar to the "spellfile.vim" plugin, can
make the request to the web repository to download and install the
required file. This is the only required plugin that should be included
to the official vim distribution.
The functions should return *expected* values and data types and though
obviously the implementation can be under development, the developer doesn't
have to care about (the implementation). This is a concept similar or known
as "encapsulation" in the object oriented languages.
Problems that have to be resolved, or things that have to be done:
- a mailing list; a vim_plugin perhaps
- a host for the project (code google?)
- a version control system (svn, mercurial or git are popular and
portable solutions (there is a git port for windows I think))
Possible system enhancements or things that need decisions:
- a function database
- separation of the implementation and the configuration
- a quoting from Bram:
"If there is one thing I would like to work on, given enough time, is
to compile Vim script into some kind of byte code."
that will give a boost to the plugin performance
That was just a first draft, that can be serve for inspiration or just
to be the first brick of a stable, flexible and viable 'plugin'
system/foundation. It's based on personal experiments and from the work
of Marc Weber and Luc Hermitte.
But it's really up to the community to create something exciting, practical
and useful, for the benefit of the current user base and for the next
generation of vim users.
> John
Regards,
Ag.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
