Create vimballs from the command-line

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Create vimballs from the command-line

Tom Link-3

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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

James Vega-3
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 <[hidden email]>

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Charles Campbell

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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Matt Wozniski-2

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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Charles E Campbell Jr

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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Doug Kearns
In reply to this post by Tom Link-3

On 2/11/09, Tom Link <[hidden email]> 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.

<snip>

Regards,
Doug

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Tom Link-3

> 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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Matt Wozniski-2
In reply to this post by Charles E Campbell Jr

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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Tom Link-3

> 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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Matt Wozniski-2

On Wed, Feb 11, 2009 at 11:06 AM, Tom Link <[hidden email]> 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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Tony Mechelynck
In reply to this post by Charles E Campbell Jr

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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Tony Mechelynck
In reply to this post by Matt Wozniski-2

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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Tony Mechelynck
In reply to this post by Tom Link-3

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 yelloooooww!
                  "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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Gary Johnson-4
In reply to this post by Tony Mechelynck

On 2009-02-12, Tony Mechelynck <[hidden email]> 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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Charles E Campbell Jr

Gary Johnson wrote:

> On 2009-02-12, Tony Mechelynck <[hidden email]> 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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Matt Wozniski-2
In reply to this post by Tony Mechelynck

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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Tony Mechelynck
In reply to this post by Gary Johnson-4

On 12/02/09 02:07, Gary Johnson wrote:

> On 2009-02-12, Tony Mechelynck<[hidden email]>  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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Tom Link-3
In reply to this post by Tony Mechelynck

> 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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Andy Wokula
In reply to this post by Charles E Campbell Jr

Charles E. Campbell, Jr. schrieb:

> Gary Johnson wrote:
>> On 2009-02-12, Tony Mechelynck <[hidden email]> 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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Create vimballs from the command-line

Tony Mechelynck

On 12/02/09 21:52, Andy Wokula wrote:

> Charles E. Campbell, Jr. schrieb:
>> Gary Johnson wrote:
>>> On 2009-02-12, Tony Mechelynck<[hidden email]>  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
-~----------~----~----~----~------~----~------~--~---

12