Charles E Campbell Jr wrote:
[...]
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.
Regards,
Chip Campbell
Looking at the vimball plugin, I notice it always unpacks into
directories of the first (existing) directory in 'runtimepath'. That is,
into ~/.vim/something or ~/vimfiles/something if they exist. The
description (at vim-online) of the netrw plugin also recommends to
remove the version under $VIMRUNTIME. This has two consequences:
- It is not possible to install a vimball (such as a new version of the
netrw plugin) system-wide under $VIM/vimfiles unless ~/.vim or
~/vimfiles does not exist.
- If the recommendations at vim-online are followed, the netrw
functionality (including local directory browsing) will be made
unavailable to all users except the one who installed the new version.
The above may be intentional but I believe it is a severe drawback. It
is admittedly documented under ":help :Mkvimball" but not under
"install details" at
http://vim.sourceforge.net/scripts/script.php?script_id=1075 (where
"your .vim/ or vimfiles\ directory" can be construed as including
$VIM/vimfiles); and searching that HTML page for "vimball" gives a null
result so anyone not already knowing about vimballs won't be drawn to
the pi_vimball.txt helpfile.
Suggestion 1: I suggest to add optional additional parameters to the
vimball commands:
:MkVimball filename [path]
:UseVimball [filename] [path]
Maybe even (but perhaps less iimportant)
:MkVimball filename [path] [EMAIL PROTECTED]
where "filelist" is a file containing one filename per line, relative to
[path] or, by default, to the first existing directory in 'runtimepath'.
As a further refinement (I'm "thinking aloud" here) maybe the result of
applying :redir to UseVimball/VimballList could be acceptable too.
This would allow:
1) creating a vimball from files located elsewhere than in "the
first existing directory in 'runtimepath'". The following possible
locations come to mind:
$VIM/vimfiles (the system-wide non-distribution tree in
'vimruntime')
~/.build/vim/vim70 (a directory tree used to build vim but not
necessarily for execution on this machine)
/home/myusername/.vim (a Vim directory tree for a different
user, e.g. when done from an admin account having implicit +rw
permissions everywhere)
2) unpacking a vimball other than the current file and/or to some
non-default location. The same locations as above come to mind, and in
addition a not-yet-existing ~/.vim or ~/vimfiles
3) by making then unpacking a vimball, copying a series of related
vim scripts from one location to another (for instance, from /root/.vim
and its subdirectories to the corresponding locations in and under
/home/user1/.vim but not to /home/user2/.vim).
4) optionally, keeping a disk record of which files belong to a
given project, in a format acceptable to :MkVimball, to streamline the
creation of the relevant vimball.
A cursory glance at plugin/vimball.vim and autoload/vimball.vim seems to
indicate that this suggestion (which, IIUC, wouldn't break existing
functionality) wouldn't be too hard to implement, but of course you know
those plugins much better than I do. If you want me to suggest a patch,
ay so, and I will try.
Suggestion 2: I also suggest to explicitly mention vimballs in the
vim-online blurbs for vimballed scripts.
Best regards,
Tony
