Gary Johnson wrote:
On 2007-03-16, "A.J.Mechelynck" <[EMAIL PROTECTED]> wrote:
Here is how to avoid "modifying system files": Since there is a test at the
start of the netrw scripts to avoid double sourcing, you can test them by
unvimballing them under $VIM/vimfiles, $HOME/vimfiles or $HOME/.vim,
without removing the older files under $VIMRUNTIME (I know the latter is
contrary to Dr. Chip's recommendations, but it works). You will just have
to watch out and remove the "user versions" of the scripts if and when the
normal Vim upgrade process installs a newer version under $VIMRUNTIME.
In my experience, installing the newer netrw files under
$VIM/vimfiles or $HOME/.vim does _not_ work unless you also delete
the corresponding "system" netrw files under $VIMRUNTIME. I have
installed vim 7.0 on several systems:
- HP-UX 10.20 from source;
- SunOS 5.8 from source;
- Red Hat Linux 9 from source;
- Cygwin pre-compiled;
- Cygwin from source;
- Windows XP pre-compiled from vim.sf.net;
- Windows XP pre-compiled from Cream;
and in every case, when the new "private" netrw files were used
without deleting the "system" netrw files, an edit of a directory
would fail, showing only an empty buffer.
I would have thought that the usual anti-double-sourcing checks
would work for netrw, too, but apparently they don't.
Regards,
Gary
Well, I have done it too, under Windows XP SP2 (with, IIRC, the non-Cream Vim
from Steve Hall's Cream project) and under SuSE Linux 9.3 (with Vim compiled
from the official sources), and it worked for me. Only though, if the netrw
versions were close enough so that the structure (name and relative path) of
the netrw files were the same in both versions.
In all cases, checking for netrw scripts' versions under $VIMRUNTIME remains
necessary after every upgrade.
Best regards,
Tony.
--
A formal parsing algorithm should not always be used.
-- D. Gries
