Re: Create vimballs from the command-line
Gary Johnson wrote: > On 2009-02-12, Tony Mechelynck wrote: > > >> And then there are people like me who can un- .zip files if they have >> to, but prefer to gunzip them (un- .gz), which is the Unix standard (as >> opposed to the Microsoft Megabucks LoseDough standard). And note that if >> the right tools are present (gunzip in the $PATH), a compressed vimball >> (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily >> as an ordinary one. >> > > Yes, it will, except that when you open the gzipped file with > > vim someplugin.vba.gz > > the original file is automatically gunzipped and replaced by the > gunzipped version, e.g., somefile.vba. I wish the vimball plugin > wouldn't do that. If I'm going to keep the archive around for a > while, I'd rather keep it in its gzipped form. Besides, I should be > able to use vim to just look at a file without modifying it. > Hello! The latest vimball (v30h) is now available from my website (http://mysite.verizon.net/astronaut/vim/index.html#VIMBALL). The decompression is now deferred until the file is sourced (ie. one may now browse the file without decompressing it on your hard disk). Sourcing a file still requires that the file be decompressed first. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
Gary Johnson schrieb: > On 2009-02-12, Tony Mechelynck wrote: > >> And then there are people like me who can un- .zip files if they have >> to, but prefer to gunzip them (un- .gz), which is the Unix standard (as >> opposed to the Microsoft Megabucks LoseDough standard). And note that if >> the right tools are present (gunzip in the $PATH), a compressed vimball >> (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily >> as an ordinary one. > > Yes, it will, except that when you open the gzipped file with > > vim someplugin.vba.gz > > the original file is automatically gunzipped and replaced by the > gunzipped version, e.g., somefile.vba. I wish the vimball plugin > wouldn't do that. If I'm going to keep the archive around for a > while, I'd rather keep it in its gzipped form. Besides, I should be > able to use vim to just look at a file without modifying it. > > Regards, > Gary I fully agree. -- Andy --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 12/02/09 21:52, Andy Wokula wrote: > Charles E. Campbell, Jr. schrieb: >> Gary Johnson wrote: >>> On 2009-02-12, Tony Mechelynck wrote: >>> >>> And then there are people like me who can un- .zip files if they have to, but prefer to gunzip them (un- .gz), which is the Unix standard (as opposed to the Microsoft Megabucks LoseDough standard). And note that if the right tools are present (gunzip in the $PATH), a compressed vimball (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily as an ordinary one. >>> Yes, it will, except that when you open the gzipped file with >>> >>> vim someplugin.vba.gz >>> >>> the original file is automatically gunzipped and replaced by the >>> gunzipped version, e.g., somefile.vba. I wish the vimball plugin >>> wouldn't do that. If I'm going to keep the archive around for a >>> while, I'd rather keep it in its gzipped form. Besides, I should be >>> able to use vim to just look at a file without modifying it. >>> >> The reason why it does that: one can't source a buffer, and one can't >> source a compressed file. >> >> Regards, >> Chip Campbell > > The question is, why vimballs have to be :sourced at all. A vimball > archive file is not a vimscript. ":so %" is only needed to execute > ":UseVimball". So why aren't the user instructions > "Execute :UseVimball to extract this file" > It would make things much easier and all this ugly unpacking trouble > could be avoided. > A vimball _is_ a Vim script -- starting with one comment (which identifies it as a vimball), and then UseVimball finish You can _also_ extract it with :UseVimball (possibly with the optional pathname argument), as is said under ":help :UseVimball", but the vimball must be the current file open in Vim when you do that (the UseVimball command has no argument to tell it which vimball to unpack, it implicitly uses the current file). Personally, I believe that :so % is easier to type (and remember) than :UseVimball OTOH, if you want to use :UseVimball $VIM/vimfiles (which is even longer) you have to type it by hand. Best regards, Tony. -- Fertility is hereditary. If your parents didn't have any children, neither will you. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
Charles E. Campbell, Jr. schrieb: > Gary Johnson wrote: >> On 2009-02-12, Tony Mechelynck wrote: >> >> >>> And then there are people like me who can un- .zip files if they have >>> to, but prefer to gunzip them (un- .gz), which is the Unix standard (as >>> opposed to the Microsoft Megabucks LoseDough standard). And note that if >>> the right tools are present (gunzip in the $PATH), a compressed vimball >>> (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily >>> as an ordinary one. >>> >> Yes, it will, except that when you open the gzipped file with >> >> vim someplugin.vba.gz >> >> the original file is automatically gunzipped and replaced by the >> gunzipped version, e.g., somefile.vba. I wish the vimball plugin >> wouldn't do that. If I'm going to keep the archive around for a >> while, I'd rather keep it in its gzipped form. Besides, I should be >> able to use vim to just look at a file without modifying it. >> > The reason why it does that: one can't source a buffer, and one can't > source a compressed file. > > Regards, > Chip Campbell The question is, why vimballs have to be :sourced at all. A vimball archive file is not a vimscript. ":so %" is only needed to execute ":UseVimball". So why aren't the user instructions "Execute :UseVimball to extract this file" It would make things much easier and all this ugly unpacking trouble could be avoided. -- Andy --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
> WinZip (for instance) can uncompress .gz files as an easy preliminary step. 7zip[1], which is GPL licensed, handles all formats well. The point was though that vimballs cannot readily include binary data which isn't all wrong I think. [1] http://www.7-zip.org --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 12/02/09 02:07, Gary Johnson wrote: > On 2009-02-12, Tony Mechelynck wrote: > >> And then there are people like me who can un- .zip files if they have >> to, but prefer to gunzip them (un- .gz), which is the Unix standard (as >> opposed to the Microsoft Megabucks LoseDough standard). And note that if >> the right tools are present (gunzip in the $PATH), a compressed vimball >> (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily >> as an ordinary one. > > Yes, it will, except that when you open the gzipped file with > > vim someplugin.vba.gz > > the original file is automatically gunzipped and replaced by the > gunzipped version, e.g., somefile.vba. I wish the vimball plugin > wouldn't do that. If I'm going to keep the archive around for a > while, I'd rather keep it in its gzipped form. Besides, I should be > able to use vim to just look at a file without modifying it. > > Regards, > Gary That's how gunzip normally works. You can keep the compressed file by doing gunzip -c somefile.vba.gz > somefile.vba or gunzip -c somefile.vba.gz | view - which uncompresses to stdout (hence the redirection) and keeps the *.gz. (You may have a script or softlink named zcat or gzcat which is equivalent to gunzip -c). Best regards, Tony. -- "The Right Honorable Gentleman is indebted to his memory for his jests and to his imagination for his facts." -- Sheridan --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
Gary Johnson wrote: > On 2009-02-12, Tony Mechelynck wrote: > > >> And then there are people like me who can un- .zip files if they have >> to, but prefer to gunzip them (un- .gz), which is the Unix standard (as >> opposed to the Microsoft Megabucks LoseDough standard). And note that if >> the right tools are present (gunzip in the $PATH), a compressed vimball >> (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily >> as an ordinary one. >> > > Yes, it will, except that when you open the gzipped file with > > vim someplugin.vba.gz > > the original file is automatically gunzipped and replaced by the > gunzipped version, e.g., somefile.vba. I wish the vimball plugin > wouldn't do that. If I'm going to keep the archive around for a > while, I'd rather keep it in its gzipped form. Besides, I should be > able to use vim to just look at a file without modifying it. > The reason why it does that: one can't source a buffer, and one can't source a compressed file. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On Wed, Feb 11, 2009 at 7:29 PM, Tony Mechelynck wrote: > > On 11/02/09 16:23, Matt Wozniski wrote: > [...] >> 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. > [...] > > For backward compatibility, *.vba shouldn't be a zipfile under another > name (which .xpi and .jar are, but these extensions were never used for > something else before). *.vba.gz (keeping the .vba as-is and compressing > them for transport, the way .tar.gz relates to plain .tar) would be easy > to implement; if you want something more complicated than this, I > believe a new extension would be necessary. Yes, I realized that after sending that email off - I was thinking about it providing backwards compatibility in the sense that the install process for a zip-based vimball and a vimscript-based vimball could be made largely the same, but at the time of writing it didn't even occur to me that the old vimball install scripts would mangle it. Oops. ~Matt --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 2009-02-12, Tony Mechelynck wrote: > And then there are people like me who can un- .zip files if they have > to, but prefer to gunzip them (un- .gz), which is the Unix standard (as > opposed to the Microsoft Megabucks LoseDough standard). And note that if > the right tools are present (gunzip in the $PATH), a compressed vimball > (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily > as an ordinary one. Yes, it will, except that when you open the gzipped file with vim someplugin.vba.gz the original file is automatically gunzipped and replaced by the gunzipped version, e.g., somefile.vba. I wish the vimball plugin wouldn't do that. If I'm going to keep the archive around for a while, I'd rather keep it in its gzipped form. Besides, I should be able to use vim to just look at a file without modifying it. Regards, Gary --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 11/02/09 06:42, Tom Link wrote: >> You can specify the base path with the final arg to MkVimball. > > If you wanted to create vimballs from cygwin bash by calling Windows > gvim (you could of course use cygwin's vim but ...), you'd have to > convert the path which works most of the time but can be cumbersome. > But thanks for reminding me of that extra argument. > > Regards, > Thomas. IMHO it makes sense to have a non-GUI version of Vim-for-Cygwin and use that under Cygwin bash in preference to native-Windows versions. Or, if your Cygwin Vim is too outdated, you can run native-Windows Vim at the cmd.exe command line. In both cases, I believe (but didn't check) that you could use (for instance, and with the extra argument) vim -u NORC -N -es -c 'MkVimball filelist $VIM/vimfiles' -cq if you didn't want to bother with an interactive Vim session. Best regards, Tony. -- BRIDGEKEEPER: What is your favorite colour? GAWAIN: Blue ... No yelloww! "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 11/02/09 16:23, Matt Wozniski wrote: [...] > 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. [...] For backward compatibility, *.vba shouldn't be a zipfile under another name (which .xpi and .jar are, but these extensions were never used for something else before). *.vba.gz (keeping the .vba as-is and compressing them for transport, the way .tar.gz relates to plain .tar) would be easy to implement; if you want something more complicated than this, I believe a new extension would be necessary. Best regards, Tony. -- The correct way to punctuate a sentence that starts: "Of course it is none of my business, but --" is to place a period after the word "but." Don't use excessive force in supplying such a moron with a period. Cutting his throat is only a momentary pleasure and is bound to get you talked about. -- Lazarus Long, "Time Enough for Love" --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 11/02/09 03:48, 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. > > 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). >> 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. > > 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). > > Chip And then there are people like me who can un- .zip files if they have to, but prefer to gunzip them (un- .gz), which is the Unix standard (as opposed to the Microsoft Megabucks LoseDough standard). And note that if the right tools are present (gunzip in the $PATH), a compressed vimball (*.vba.gz) will (if I'm not mistaken) be handled by Vim just as easily as an ordinary one. For you poor serfs of Bill Gates, WinZip (for instance) can uncompress .gz files as an easy preliminary step. (Last I checked, it couldn't do .bz2 though.) OTOH I have had encoding compatibility problems in the past but I solved them manually and I don't remember exactly what they were. I think they were related to the fact that my vimrc includes ":setglobal fenc=utf-8 bomb" for new files and that it sometimes created problems if there already were differently-encoded files in the same directories. As for line-ending format differences, "portable scripts" can be distributed in only the Unix version (LF-without-CR) since Vim-for-Windows and Vim-for-Mac can edit and source them with no problem unless a nondefault 'fileformats' setting explicitly makes it incompatible with them. People who (like me) don't always want to unpack the vimball into the first tree in 'runtimepath' can always use the :UseVimball command with an explicit path at the command-line rather than by sourcing the vimball. (It often makes sense to unpack a vimball globally into $VIM/vimfiles rather than user-privately into ~/.vim or ~/vimfiles even if one of the latter exists. This is a feature which Dr. Chip added at my suggestion two and a half years ago.) Yes, vimballs, like many Vim features, do take some getting used to (and it took me some time to get used to them); but I believe they are a worthwhile component. Best regards, Tony. -- There was a young whore from Kaloo Who filled her vagina with glue. She said with a grin, "If they pay to get in, They can pay to get out again too!" --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On Wed, Feb 11, 2009 at 11:06 AM, Tom Link wrote: > >> 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. > > IMHO reliance on compiled-in +python support would make things even > more complicate that relying on unzip being installed -- which maybe > could be even shipped with vim? BTW the zip plugin work quite well, > even when using bash under windows. I was suggesting just the opposite - that we shouldn't *rely* on +python, but that if python were available we wouldn't have to rely on an external unzip. Which may or may not be worthwhile - I guess it depends on which supported platforms don't include an 'unzip' (win 9x? Amiga?) and whether most binaries on those platforms have +python (probably not, so the entire exercise might well be pointless). I was just pointing out a possibility that might be worth considering. :-) > BTW maybe a vba (zip-based or not) could include some sort of manifest > file that includes not only a file list but also dependencies on other > plugins? These manifests could be saved in, eg, ~/vimfiles/vimballs/ > manifests/ and be used for downloading the dependencies and for > removing vimfiles (AFAIK the uninstall info is currently saved in a > single file, which could cause minor conflicts when syncing vimfiles > directories between several computers). Just a thought. Sounds like a reasonable suggestion to me. ~Matt --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
> 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.
"installing" zip-based plugins basically is a matter of
exec '!unzip '. shellescape(expand('%')) .' -d ~/vimfiles'
:helptags ~/vimfiles/doc
IMHO reliance on compiled-in +python support would make things even
more complicate that relying on unzip being installed -- which maybe
could be even shipped with vim? BTW the zip plugin work quite well,
even when using bash under windows.
BTW maybe a vba (zip-based or not) could include some sort of manifest
file that includes not only a file list but also dependencies on other
plugins? These manifests could be saved in, eg, ~/vimfiles/vimballs/
manifests/ and be used for downloading the dependencies and for
removing vimfiles (AFAIK the uninstall info is currently saved in a
single file, which could cause minor conflicts when syncing vimfiles
directories between several computers). Just a thought.
Regards,
Thomas.
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
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 -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
> You can specify the base path with the final arg to MkVimball. If you wanted to create vimballs from cygwin bash by calling Windows gvim (you could of course use cygwin's vim but ...), you'd have to convert the path which works most of the time but can be cumbersome. But thanks for reminding me of that extra argument. Regards, Thomas. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 2/11/09, Tom Link wrote: > > Hi folks, > > Maybe somebody has some use for this. I wrote a small ruby script that > allows the creation of vimballs (plain text or gzipped) from the > command line. It's still young and fresh and experimental. I ran it > over my own plugins and the generated vimballs are identical to those > created by vimball.vim. Tested with ruby 1.8 (cygwin). > > Raison d'être: I wanted something that can run from a makefile and > that doesn't care about the runtimepath. You can specify the base path with the final arg to MkVimball. Regards, Doug --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
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. 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). > 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. 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). Chip --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On Tue, Feb 10, 2009 at 4:35 PM, Charles Campbell wrote: > James Vega wrote: >> >> I'm still curious what purpose vimballs serve over a standard archive >> format like zip or tar.gz. From a distribution perspective, all they've >> done is made my work harder when trying to include vim scripts in a >> package for a Linux distribution. >> > * they automatically enable help for any enclosed help files > * files go where they need to; they're not dependent on the user > changing to the appropriate directory first. > * one may uninstall the files extracted by a vimball (:RmVimball > vimballname) > * the vimball itself requires no addtional tools beyond vim itself > (compression/decompression is another matter) 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. 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. 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. ~Matt --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
James Vega wrote: > On Tue, Feb 10, 2009 at 12:53:15PM -0800, Tom Link wrote: > >> Maybe somebody has some use for this. I wrote a small ruby script that >> allows the creation of vimballs (plain text or gzipped) from the >> command line. >> > > I'm still curious what purpose vimballs serve over a standard archive > format like zip or tar.gz. From a distribution perspective, all they've > done is made my work harder when trying to include vim scripts in a > package for a Linux distribution. > > * they automatically enable help for any enclosed help files * files go where they need to; they're not dependent on the user changing to the appropriate directory first. * one may uninstall the files extracted by a vimball (:RmVimball vimballname) * the vimball itself requires no addtional tools beyond vim itself (compression/decompression is another matter) Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On Tue, Feb 10, 2009 at 12:53:15PM -0800, Tom Link wrote: > Maybe somebody has some use for this. I wrote a small ruby script that > allows the creation of vimballs (plain text or gzipped) from the > command line. I'm still curious what purpose vimballs serve over a standard archive format like zip or tar.gz. From a distribution perspective, all they've done is made my work harder when trying to include vim scripts in a package for a Linux distribution. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Create vimballs from the command-line
Hi folks, Maybe somebody has some use for this. I wrote a small ruby script that allows the creation of vimballs (plain text or gzipped) from the command line. It's still young and fresh and experimental. I ran it over my own plugins and the generated vimballs are identical to those created by vimball.vim. Tested with ruby 1.8 (cygwin). Raison d'être: I wanted something that can run from a makefile and that doesn't care about the runtimepath. Download: http://github.com/tomtom/vimtlib/blob/a2f709d195f708147db51e79274155e51f7b7b47/ruby/vimball.rb Please tell me if the script doesn't work with your recipes/vimballs. Regards, Thomas. --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
