As you asked me to join your effort, I ask you to join mine to refresh the 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 . 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 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 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('') ]") 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 /maillist.php -~----------~----~----~----~------~----~------~--~---
