Victor Hsieh wrote:
With vim 7.0 and netrw.vim version 98, I've encountered a problem
when trying to "vim http://somewhere/file.txt";. This patch will fix
the problem:
============
--- netrw.vim 2006-10-06 13:53:03.567758750 +0800
+++ netrw.vim.orig 2006-10-06 13:47:02.757209500 +0800
@@ -753,7 +753,7 @@
call tar#Browse(tfile)
else
" call Decho("edit temporary file")
- e
+ e!
endif
" rename buffer back to remote filename
============
This would silently let users overwrite their own work that they had not
saved.
I don't think this would be a good idea.
BTW, when I try to "vim http://somewhere/dir/"; (with slash at the
end), it'll try to connect to ftp://somewhere/dir/ instead of returned
html. If you look at netrw.vim, there's a snippet of code like this:
if method == "ftp" || method == "http"
let method = "ftp"
let listcmd = g:netrw_ftp_list_cmd
else
let listcmd =
substitute(g:netrw_list_cmd,'\<HOSTNAME\>',user.machine,'')
endif
If you remove the second line, everything is gonna be all right, even
the returned html code is parsed and vim will list the remote file
correctly. Does anybody know what's the second line for?
Netrw uses the trailing slash to determine whether to browse the remote
directory
or to bring it up for editing. Consider ftp://hostname/some/directory/
-- that trailing
slash tells netrw to display directory contents, not attempt to edit a
file called "directory".
Now, http://... normally uses wget, and there's no corresponding wput;
hence, "editing"
an http://... url is a read-only operation. So, if one tries to edit a
"directory" with the
http protocol (ie. wget), netrw does the best it can and brings it up
using ftp. Of course,
ftp is a read and write capable protocol, so one can really edit it.
Regards,
Chip Campbell
