On Tue, Feb 10, 2009 at 9:48 PM, Charles E. Campbell, Jr. wrote: > > Matt Wozniski wrote: >> But let's not forget that they have significant disadvantages, too... >> Vimballs made with new versions of the plugin don't work on older >> vims. > > There's been one problem with that -- 7.0 vimball doesn't handle the later > vimball versions. 7.1 and has been compatible; newer vimballs have largely > fixed small problems, not introduced incompatibilities.
I could swear an incompatibility was introduced when fnameescape() came along... but that might have just been for using newer versions of the plugin with older vims, not with extracting vimballs made with the newer version on older vims. If so, scratch that point off my list. > Vimball was done by request, consequently it didn't have much feedback > before > it went into 7.0. >> Considering that those writing and distributing scripts are >> much more likely to be at the bleeding edge than the users who >> download those scripts, they're quite likely to wind up distributing >> something that many of their users can't use. It's also not possible >> to include binary files in a vimball, or fines with different >> encodings, or even files with different line endings. > > I think that I could get vimball to handle binary files, which would > mean that zip > files could be embedded. However, most plugins don't need binary files > (those with > icons for signs would be an exception). Or even those that would like to include screenshots, or compiled data files... I don't doubt that vimball could be made to support things like this, I just think it would be more effort than trying to come up with a wrapper around zips that adds the features we need. >> IMHO, this makes them significantly less useful than zip files, since >> we could add those 3 nice features (automatic :helptags, extracted to >> first writable directory, uninstallable) to zip files without having >> to tolerate the disadvantages that vimball doesn't seem to be able to >> overcome... Really, it seems that depending on an unzip program being >> on the computer is far better than implementing our own >> barely-featured interface-unstable >> self-extracting-archive-that-wants-to-be-a-zipfile. I think that an >> effort to nicely encapsulate the platform differences and such of >> handling zipfiles, or possibly even one day writing a vimscript >> unzipper, would be a better use of our resources than continuing to >> maintain vimball. >> > And putting these vim-specific features into zip files would be real > popular with > the rest of the zip community, I'm sure. At the very least, it'd be > bloat for most > such users. Then some other applications would want to chime in with > their own > application specific features. Well, of course I didn't mean that we should add the features to the zip format. Rather, I meant we should do something more like XPI - create a zip file, rename it to .vba, and let vim handle it specially. The change would be transparent to users, and give more useful features to developers, without having to reinvent the wheel. > It'd be better to have a plugin that acted as a wrapper around zip to > support the > additional features that vimball provides. Probably could be a > modification to the current > zip handling plugin. The same sort of mods could be done with tar and > the tar handling > plugin, too. I'll consider doing it (after taxes and fafsas). Right. For the near term, supporting unzipping using a pure-vimscript solution isn't terribly likely, but it's definitely possible OOTB in vims built with +python, for example. ~Matt --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
