On 2006-06-13, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:
> Gary Johnson wrote:
>
> > I was following Chip Campbell's advice in the vim list to download
> > v100 of the netrw plugin when I discovered the following
> > undesirable behavior of the gzip.vim plugin. I downloaded
> > netrw.vba.gz, then opened it with
> >
> > view netrw.vba.gz
> >
> > and saw the following messages at the bottom of the screen:
> >
> > "netrw.vba.gz" [readonly][noeol] 260L, 67511C
> > "~/.vim/netrw.vba" [readonly] 7156L, 274745C
> > Source this file to extract it! (:so %)
> > Press ENTER or type command to continue
> >
> > I took a brief look at the file, then closed vim with
> >
> > :q
> >
> > When I did an 'ls' of the directory, I discovered that netrw.vba.gz
> > had been replaced by netrw.vba! I didn't want to unzip the file,
> > only look at it. I believe this is an error in the behavior of the
> > gzip.vim script.
> >
> >
> The problem here is :so % doesn't source the buffer, it sources the
> underlying file. Thus the
> file must needs be gunzip'ed first.
>
> Vimball could be set up not to gunzip the file, but then sourcing it
> would fail.
Oh, so you're saying that the unzipping of the file was a
consequence of it being a vimball, not of being a gzip archive. I
thought that vim-7.0 was now unzipping any .gz file that it opened.
I just now used vim to read a gzipped text file and a gzipped tar
file and verified that vim did not alter either of them. That's
better.
Thanks for the explanation. Considering the purpose of a vimball
the and operations you want to perform on it, the current behavior
seems fine.
Regards,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
