Marc Weber worte:
> TOVL = the one vim lib.
>
> The lib is an very early stage and much has still to be done. But let me
> tell you what the main goals are and let me invite you taking action and
> help me expand and enhance it.
>
> If you don't have much time jump in and try:
> (You may want to remove ~/.theonevimlib_config afterwards)
> $ git clone git://mawercer.de/theonevimlib
>
> add the contained core folder to your runtimepath:
> set :runtimepath+=theonevimlib/core
> and restart vim. Then execute
> :TOVLConfig
>
> You should see something like this:
> ============= snip ===================================================
> dictionary=
> example:dictionary=
> commandName:string=ExamplePluginH
> command:string=echo 'lo world to you from example plugin'
> loadablePlugins:dictionary=
> example:number=1
>
>
> [### your editing config file /home/marc/.theonevimlib_config ##### ]
> ============= snip ===================================================
>
> Try
> :Help
> to get more info. It tells you how to play with the example plugin
> redefining a very simple command or removing it if you unlead the
> plugin.
Where can we read the help before doing all this?
It sounds rather complicated. And requires git (which I don't have
installed). What's wrong with ftp, which is available nearly
everywhere?
> So what is this all about?
> I feel vim.org is nice but the vim community is lacking one feature:
> Something thate ruby, perl, php all do have: A way to get plugins fast
> and automatically. Yes there is vimball. But it did never adress all
> problems. Most of the plugins do contain mappings of the author. You
> customize them, you update the plugin and your changes are lost. TOVL
> tries to separate functionality (the lib part) from user interface
> (configuration).
I like this part. The plugin only defines the functionality, it's up to
the user to bind this to keys. But how to avoid that the user has to
set up a dozen maps for every plugin he installs? We still need
defaults.
> Using a version control system such as git you'll be
> able to up and dowgrade on the fly if something has gone wrong.
I think the whole idea of plugins is that you can rely on the plugin
writer to make sure that a newer version works better. Having to check
yourself is not nice. The excuse that you can go back a version is a
bad excuse. Version control sounds like the wrong tool to me.
> TOVL can evolve to a vim community project:
>
> * get all the code at once but only run the code you really want
> That's done by activating "plugins"
> disk is cheap, your time is not!
>
> * containing most useful scripts, mappings, code without bloat
> Because using a git repository everyone can commit to and remove
> or enhance code. This should result in a very nice vim library
> everyone likes to work with.
If everyone can commit, how do you avoid people breaking someone else's
script? Or adding malicious stuff? You need access control. You need
to manage users. You need documentation. Doesn't this sound like a
SourceForge/code.google.com/etc. project?
> * Make people starting to learn vim more productive because they
> can jump in and enable those plugins without the need to
> read all the vim tips.
I stongly object to enabling something that you don't know what it's
going to do. Especially if you don't even know where it's coming from.
Every script you enable must have documentation you read before using
it. Unless it's part of a core set of plugins that everybody uses.
> * no longer waste dev time rewriting the same stuff again and again.
> (such as template systems etc).. We should try to get all features
> into one "plugin" and enhance that. I think there is still enough
> which can be improved.
Rewriting stuff can be much quicker than agreeing on "one way" and
putting everything into one. It depends.
> * maybe integrate a dependency system to create isntaller only
> adding the library files which are actually needed.
> (Some of the code is already there. But I still have to clean it up)
It's best to resolve dependencies the moment you get a plugin. Not when
using it. The autoload mechanism works well. We do need some way to
handle shared autload scripts.
> * don't ever override configurations by accident while running
> multiple vim instances. Configuration changes are written to
> disk and reloaded by the other instances automatically.
Amazing.
> * more to be done.
>
> Of course a lot of things are still missing in the configuration
> editor: highlighting, completion, ... I'll add featuers piecwise.
> (Maybe you want to help me?)
>
> Please read the top level README and tell me about your feelings?
>
> It is still a prototype. I need your input to make it even better.
>
> It may become a replacement of most scripts. But at the beginning I'd
> like to make it only a collection of exsisting scripts.
I have mixed feelings about this. A claim to have the one and only
solution to a problem is usually false. But there can be some useful
parts here.
--
ARTHUR: I am your king!
WOMAN: Well, I didn't vote for you.
ARTHUR: You don't vote for kings.
WOMAN: Well, 'ow did you become king then?
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
