> > > I personally think part of the problem is that vim is a rather fragile > environment (because it's a really versatile editor that can adapt to > different usage styles). A script that works well for me doesn't > necessarily work for you because you use different options etc. and > IMHO it is too much to ask from script authors to take into account > all possible options.
But it doesn't have to be. A simple solution like an environment stack(store the current env onto a stack, make any changes, pop it off to restore the old env) would make it handleable. But no one makes code to make other peoples coding easier because other people have to actively seek it out. They don't even see the problem, much less the solution. > So the solution to this "problem", if it really exists, seems to me to > be rather a social evolutionary one in that script authors should get > better feedback on their scripts, and users should provide more/better > feedback (instead of simply uninstalling the script and moving on to > the next one). In conjunction with a slightly improved assessment > system, in time bad plugins would disappear and good plugins would be > ranked top. > > The karma points were a nice system to get an idea of how good a > script is. But there is room for improvements. Eg scripts could lose > karma points (or votes) over time in order to weed out unmaintained > scripts. Also, some people seem to have manipulated the karma points > (eg check out the powershell files) -- I guess you wouldn't even have > to write your own script if you used curl. So maybe there should be a > captcha for people who want to vote on a script. And maybe 1 to 5 > stars + number of votes would give people a more concise idea of a > script's quality. Nothing you're saying here is wrong, except your only solution to a bugged script is to vote it down. That implies that someone will post a 'corrected' version that will get voted up. And that people will come back long after they downloaded and started using a script to vote it down if they find a hidden bug. Slightly better would be to allow anyone to edit scripts wiki style. But you're still relying on them stopping what they're doing, loading up a web page and changing it. And if they're making a change based on their environment there's a high likely hood that it's wrong and will break it for someone else. And everyone who already has this script doesn't even realize there are broken versions floating around because no one updates it if it works. The centralized repository forces you to upgrade and could(should) have a simple mechanism for reporting bugs(and submitting patches). No one has to go to an outside application. Futhermore by encouraging code resuse we avoid God only knows how many bugs in the first place. If every script needs to impliment their own environment stack function, we may be in trouble when 2 overlap. If there's only one environment stack, then they are working with the same data. Here's the rub though, why can't we do both? If hundreds of people volounteered to get involved with this project it still wouldn't be operational for months. And even when it was, there will still be scripts that don't fit into what should go into a VimL Centralized Repository(VCR). They can still be available under the current system, but things that should be the same everywhere can be moved into the VCR(I'm trademarking that term). The current system is ad-hoc and full of misplaced intelectual capitol. It was a great try and shouldn't be thrown away but it can definatly be improved upon. I think that what Ag suggests is a massive leap in the right direction. Now if you'll excuse me, I have to go write an environment stack function. --Whaledawg --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
