Enabled DAV processing for a subdirectory of my site (http://example.com/user1/dav/ , for instance). When trying to run the following... vim dav://example.com/user1/dav/ ...I see the following in my server's access logs: xxx.xxx.xxx.xxx - - [26/Feb/2005:11:19:15 -0500] "OPTIONS /" 200 - "-" "cadaver/0.22.2 neon/0.24.7" xxx.xxx.xxx.xxx - - [26/Feb/2005:11:19:15 -0500] "PROPFIND /" 405 357 "-" "cadaver/0.22.2 neon/0.24.7" Obviously, a 405 will be returned for that URL, since DAV processing isn't enabled for it. Reproducible: Always Steps to Reproduce: 1. Install DAV-enabled server; I use mod_dav with apache. 2. Activate DAV processing for a subdirectory of the site: DAVLockDB /var/lock/DAV/DAVLock (or whatever) <Location /user1/dav> DAV on </Location> 3. Set up the DAV repository ls -la /path/to/dav drwxrws--- 3 user1 webserver-group 160 Feb 25 16:41 . 4. emerge cadaver 5. verify that cadaver can access the repository 6. Add the following to ~/.vimrc (client side) to quell warnings: let g:netrw_uid = "" let g:netrw_passwd = "" 7. vim dav://$server/path/to/dav/file.txt Actual Results: See 'details section' Expected Results: File should be pulled down from the repository This problem has been fixed in the updated netrw.vim script, available at: http://www.vim.org/scripts/script.php?script_id=1075 The notes say that the update will be included in vim7, but it would be nice to have this in vim6. Of course, one can simply install the updated netrw.vim into ~/.vim/plugin, but since this update appears to be fairly trivial to implement, I can't any obvious reason NOT to do it. =) Portage 2.0.51-r15 (default-linux/x86/2004.0, gcc-3.4.3, glibc-2.3.4.20050125-r0, 2.6.9-gentoo-r10n i686) ================================================================= System uname: 2.6.9-gentoo-r10n i686 Intel(R) Pentium(R) 4 CPU 2.80GHz Gentoo Base System version 1.6.9 Python: dev-lang/python-2.2.3-r5,dev-lang/python-2.3.5 [2.3.5 (#1, Feb 20 2005, 16:30:48)] dev-lang/python: 2.2.3-r5, 2.3.5 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.7.9, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r4 sys-devel/libtool: 1.5.10-r5 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium4 -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache distlocks sandbox sfperms userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X apm arts avi berkdb bitmap-fonts crypt emboss encode esd f77 fam font-server foomaticdb fortran gdbm gif gnome gpm gtk gtk2 imlib jpeg libg++ libwww mad mikmod mmx motif mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl slang spell sse ssl svga tcpd truetype truetype-fonts type1-fonts usb xml xml2 xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
Hrm. Options are: 1) shipping an updated netrw with vim-core 2) breaking netrw out into its own package, making vim-core PDEPEND on it and removing netwr from vim-core 3) making netrw into its own package, leaving vim-core alone and doing lots of weird scary block voodoo to get sane versioning I'm kinda thinking (1) is sanest... Alternatively, vim7 is in the tree and package.mask'ed if you want a quick solution :)
#1 certainly seems the sanest to me, although I'd probably diff the version currently being shipped with the version on the vim.org website and make it a patch. That way, if for some reason folks don't want the update, they can tweak the ebuild. Or is that what you had in mind? =)
Yeah, I was going to do it as a patch, since we already have a nice easy patch framework set up. I'll be doing a new vim-core soon, I'll include an updated netrw in that.
Should be fixed in 6.3.068.