> As you asked me to join your effort, I ask you to join mine to refresh
> the vim.org site! :-)
You should get in touch with me so that you can tell what has to be done
next. I'd vote for a way to comment scritps. This would make things much
better.
On Sat, Dec 13, 2008 at 08:44:50PM +0100, Thomas Koch wrote:
> [..] I do agree very much
> with you, that the current state of plugins in VIM is horrible at least,
> but I don't think that your proposed solution is the right one.
>
> 1. Distributions have their own package management system and their way
> of shipping vim plugins[1]. And I prefer very much to use the package
> management system of my distribution for updating and dependency
> management.
The thing is : what is a plugin? I don't think it's worth creating a
debian plugin for 10 lines of script which can make your life easier.
But those 10 lines are worth making a small plugin and giving it some
minimal documentation so that those 10 lines can be found and used.
I was driven by some experiences when creating this new library:
a) Really the really nice database script. But what the fuck?
It did ask me again and again for 10 configuration values because I
accidently used a mapping or the wrong command?
(Even if I had run it intenionally it would'nt have been nice to use)..
b) Which tool to use if you have a list and want the user to pick one
item? use inputlist? It sucks because you have to type the number and
<cr>. That's one key too much. It also sucks because it doesn't print
the item numbers before the lines. so you do have to do this yourself..
I've implemented a solution using inputlist. It prefixes the lines
with its index so that you know which number to type. You also don't
have to type the trailing <cr> if the selection is not ambiguous.
Now I think kind (give the user a list and let it choose one item) is
very common. Does vim provide a really good builtin method for this?
Maybe I've missed it. I've spend time writing this function. Tom Link
has done much better. You have a list which you can filter. (Look for
TToC).. And I really think all plugins would benefit using those nice
functions. Why? Because its much faster. And you are already using vim
because it makes you fast.
Now consider the plugin policy: Where does vim run?
ubuntu, nixos (my favourite distro), debian, winxp,
vista, *bsd, gentoo, .. whatnot
Do you really want to ask all those package mantainers to packgage a lot
of scritps? And what about windos? Create Windows installer for 50 lines
of code? What a waste of time..
Do you know why eg ruby has been that succesfull? (Or pear..) You can
just get the code easily.. No matter which system you're using.
So I say : I disagree with that policy.. I want to use OS-packages for
* packages it would take me much time to compile them myself
* big packages which should be shared on the system (such as open
office)
Neither is true for vim scripts.
Now consider the case that such a "let the user select an item" function
changes its interface for whatever reason? If you have one code base the
one enhancing the function can use search and replace and eveything
works again. You prefer having many individual packages mantained by
different mantainers maybe the one doesn't know that the next uses his
function at all! The result must be broken code..
This even happend to me when trying to install tlib and the TToC
plugin although both have been written by the same mantainer..
If I hadn't installed the package before knowing that it did work well
maybe I would have given up. That's why I vote fore the "one" library
containing most useful code. That things can be enhanced and fixed more
easily. I even want to say you need this if you want to grow to get even
better scripts. And we all need better scripts (completions, code
navigation) because competitors such as Eclipse do exist. And they do
provide install and take off features. I fear that newcomers will use
Eclipse intead and not even try vim. That's bad for me because I do want
to use a system which will grow in the future as well. That's the main
reason why I've started TOVL. And if it doesn't work maybe I'll switch
to another solution in the future. But I don't want to because I love
vim.
For those newcomers (we all depend uppon in some way) a common question
is: How to become productive when editing
C or pyhton, or html, ....
and there are some things I learned only recently (although I've been
using vim for over 3 years now extensively).. One of those things is
that you should run php - l % to syntax check your file immediately
after writing. If you keep things separate you'le likely to miss a cool
feature which provides value to you.
If you have one library you can have a .txt help file for most common
use cases such as
a) Web developpemnt using
php
ruby
python
...
and least all the features. This way you won't miss them. Maybe you do
not use them but you've read about them.
Such a list will give you much more value than say www.vim.org and using
the search.. I also want a system which I can install within 2 minutes
to get productive somewhere else without backing up my ~/.vim before.
(backing up .vim is a solution for you. But its a nogo for me if you
want to share scripts because your .vim/ directory is very likely to
contain a lot of stuff someone else doesn't need! So what do you do?
Either you don't share (bad) or you start removing stuff first (bad - takes
time)..
I'v alread been telling you why disagree you on 2.:
> 2. Keep thinks independent! I really dislike the idea of hawing one big
> thing containing many plugins. It's like in software programming:
> Have many small, independent, solid, interchangeable blocks to build
> great systems.
May I quote you again :
" I do agree very much with you, that the current state of plugins in
VIM is horrible at least, "
^^^^^^^^
That's the point. It is neither great nor solid. There are
interchangeable blocks which do not work together without heavy
tweaking.
So why why why the hell is it that way? Vim is one of the oldest editors
around. So there should have been plenty of time to get this right. Why
didn't it happen? So something must be wrong with the current system.
I'd say terrible wrong. Nobody starts enhancing it because it takes to
much time for each individual person.
But why am I talking to you anymore. You already told me that you won't
have time.
Anyway: If you have a closer look at my README file (top directory)
you'll see that I've created two directories:
core/
contrib/
contrib was meant to contain many individual interchangable vim scripts.
However who does want to start tracking a 80 line script?
How much subrepositorie would you have then?
Git can handle this all easily. I've even written it down in the README.
You can even just add your old vim/{plugin,ftplugin,doc..} directory and
only use a small wrapper adding that directory to the runtime path on
demand. Support for this all is already there. I just do think that you
must have the chance to tidy up not only your plugin but also the code
of someone else. The benefits of this will be everyone will reading thus
writing better plugin code. And thats' a value to the community we
shouldn't miss.
So if anyone has some time left for discussion or for a small live
demontsration let me know. Ping me on irc or write an email. Don't waste
time. Ask. I'll happily point you to the lines in the documentation or
extend it.
So Thomas if you really think that the Debian policy is the way to go
what about seeing TOVL as the developement code base from which you can
extract complete plugins (only containing the necessary files)
automatically? Than Debian will have the hassle if package A got
updated to use C-2.0 but D still uses C1.-0 because there is no
mantainer anymore?
What is the alternative? use tovl and do a git pull (things will be
fixed soon because everyone will only fix some lines) or maybe reanme
C-2.0 to D puttting it into a different namespace so that you have to
start worrying about which one to use if you want to write plugins
others will use as well *not* using Debian?
Apart from that the Debian policy dosn't tell you anything about
* user configuration
* using autocommands to keep the amount of source beeing loaded on
start up as minimal as possible.
So its really even worse because you'll get some damn mappings only
because of the sys damin having had a great day installing new plugins
system wide ? (Maybe I'm wrong. I don't use Debian so correct me here,
please)
So maybe try the other way round and ask how TOVL tries to solve those
issues ?
Sorry for the long post. I had too much in my mind..
The problem I have is that nearly nobody even did try it to tell me
what's good and bad. That's a thing I don't understand: You've all spend
much time loaning vim. But you don't have some time left to try out TOVL
giving me feedback so that I can enhance doumentation and so on..
By the way the user interface abstraction should be very stable now.
You can extend it by adding different feature types. One type is
responsible for adding mappings, another for commands, the next for
adding completion functions and so one. So if your plugin introduces a
nice feature which could be used in many different contexts you can
expose it easily. I've done so for a kind of gf goto thing on cursor
handler. All it does is returning a list of locations. If you select one
which doesn't exist yet it'll be created. (neither gf nor gF do create
that resource..). so a goto handler doing roughle tha same as fg looks like
this:
new library#Function("return [ expand('<CWODR>') ]")
This could be used to jump to header files in C /C++, to modules in
python.. (or even classes in Java). You get the idea.
Marc Weber
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
