Victor Hsieh wrote:
On 10/6/06, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:
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:
This would silently let users overwrite their own work that they had not
saved.
I don't think this would be a good idea.
In this case, explicitly open the url via "vim http://..."; can be
detected, and there's no more risk. I suppose this is a possible
solution :)
Again, its not a good idea. Presumably the problem occurred because you
edited the page. OK, so what I will do is make "files" obtained with the
http://... format show up as readonly. At least you'll get an earlier
notice
that editing such files isn't a Good Idea.
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.
I know. But I just want to read the html code or so with my favoriate
editor ;) I used to do it with vim6. Actually in most case,
connecting to ftp://somewhere (when open http://somewhere) is not
gonna work.
Not if you don't have the username/password access to the site, 'tis true.
I've put a no-browsing exception in for http://... .
Please try v107b now on my website:
http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs
see "Network Oriented Reading, Writing, and Browsing"
Regards,
Chip Campbell
