On Tue, Oct 06, 2009 at 01:48:32PM +0200, Richard Pöttler wrote:
> > I think that means lots of folks will pass on trying to test or use
> > your script.  Too bad, too because it looks like you put a fair bit of
> > effort into it.
...
> Would you mind installing Archive::Extract, Config::General and 
> File::Fetch (which is included in perl 5.10), or is it an absolute no-go?

Using  modules  might  be better I think. 

Maybe  add  some boilerplate CPAN.pm commands to update them, plus  an
apt-get/aptitude/yum command in case some of these are packaged on one
of  more of the larger distros (but I'd probably restrict that  myself
to just debian or ubuntu). 

Furthermore  AFAIR  CPAN.pm can deal with dependencies. When using  an
(in)official  CPAN  dist tar ball, shouldn't it take care of  fetching
listed  prerequisites  as well from? Which means to put the script  on
cpan in addition to the script section of vim.org.



My  own  take: 

first look: 
- code looks clean. 
- ton of modules (which  is both good and bad, but given we're talking
  vim and a user's customized .vim/, there's no need to keep this a 
  standalone script). 
- sqlite.

The  use  of sqlite was what made me say: might be a nice idea,  won't
use  it. 

IMHO  we're  dealing  with  vim and text. So  I'd  really  prefer  the
database  format  to be a textfile as well. Instead of making it  into
the    3-jump   sqlite3   something-dump-or-other;   vi   ;    sqlite3
something-recreate-new-db-or-other.



Final  note:  

If  not  already  documented: 

(1)  I'd like to know what the script is actually doing and storing in
addition  to  just  replicating the information from the  file  system
(maybe  something like version information, user changes, URL location
for  updates).  Might  be already part of the docs, might be  for  the
wishlist.

(2)  The vimballs already retain some information of installed scripts;
depending  on size, speed and use-frequency, something similar  might
suffice.


[(1)      is     certainly     telling     for     my     speed     of
safe-for-future-reference,for-now-ignore  on seeing the string  sqlite
:)]

-- 
cu
Peter l Jakobi
[email protected]

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply via email to