On Fri, Feb 6, 2009 at 1:50 PM, Larson, DavidX S
<[email protected]>wrote:
>
> ...
>
> Hmmmm... rings a bell. Are you modeling this after the Perl CPAN module
> structure (search.cpan.org)? That setup is obviously very successful.
> Looking at the differences of perl and vim, I have a few thoughts:
>
> 1.) The "use lib..." structure in perl is built into the language, and vim
> does not have an equivalent. Perhaps this would be a good, straightforward
> feature to add to the next version of vim?
Do you have to wait for the next version? I would think it's a simple
command you would define in autoload(unless you really, really want it to
start lowercase). And if the goal(as was stated) is to keep this
*seperate*from the vim distribution then you don't want it added to
the next version
of vim at all.
> 2.) "The purpose of this project is to create stable functions to return
> values or to execute actions." That leaves out much of the valuable
> brainwork on vim.org, since many of the scripts in vim are meant to be
> self-contained, the user only needs a macro (usually) to start the script.
> Can we think of a way to include those as well?
>
Not really, if you want to model CPAN. Self contained scripts are exactly
what you should be writing if you have no idea of the env it will be run in.
If you're building a framework then scripts should use the framework,
otherwise you duplicate a huge amount of work and get some crazy
inconsistencies.
The repository would use them in that the code would be refactored to use
other functions and be used by other functions, but stand alone functions in
general would be poor practice. Note, however, that a versioning repository
gives a lot of flexability. There's no reason you couldn't put stand alone
scripts in there with a note that they need to be refactored later.
> 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!).
It's not really starting over. It's setting up a singular place for current
scripts to be re-factored to. I think very little in the way of new
intellectual capitol will be needed(good thing, I'm broke).
I would throw a few suggestions in there:
1. This highlights the other part of my original post, that VimL
development and Vim development are separate and should have thier own mail
lists/groups/bathrooms.
2. It makes much more sense to me for a simple subversion repository
under vim.org as opposed to having it hosted by google code or some other
third party. While it makes sense for an individual when you already have a
site I don't like being sent to the far corners of the internet to get
code. Also, I'd like to have access to older version of scripts or be able
to diff the latest with my modfied version.
3. I would suggest 2 more categories:
1. *autoload/lang* Since Vim is, first and foremost, an editor it
would make sense to have a separate area to support each
language. It would
hold things like code beautifiers, debugger/profiler integration and the
like.
2. *autoload/opt* This would house optional, aplication-like scripts.
For example the functionality to do curses like menu's might be under
autoload/util/curses.vim and my erotic text game which utilizes that but
wouldn't be used by any other scripts(can we start calling them
modules at
this point?) would be at autoloat/opt/CupidAches.vim
A final thought, will a move like this necessitate stronger data structures?
There isn't much you can't represent with dictionaries and lists but I could
see passing data between disparate functions getting nightmarish. Would a
simple "named dictionary" with pre-defined keys and default values(a struct)
make life a lot easier?
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
