Updated runtime files.
diff --git a/runtime/doc/pi_netrw.txt b/runtime/doc/pi_netrw.txt
index 5c80095..914c576 100644
--- a/runtime/doc/pi_netrw.txt
+++ b/runtime/doc/pi_netrw.txt
@@ -532,7 +532,7 @@
let g:netrw_sftp_cmd= '"c:\Program Files\PuTTY\psftp.exe"'
<
(note: it has been reported that windows 7 with putty v0.6's "-batch" option
- doesn't work, so its best to leave it off for that system)
+ doesn't work, so it's best to leave it off for that system)
See |netrw-p8| for more about putty, pscp, psftp, etc.
@@ -1206,7 +1206,7 @@
invoked in the session).
The file ".netrwbook" holds bookmarks when netrw (and vim) is not active. By
-default, its stored on the first directory on the user's |'runtimepath'|.
+default, it's stored on the first directory on the user's |'runtimepath'|.
Related Topics:
|netrw-gb| how to return (go) to a bookmark
@@ -1431,7 +1431,7 @@
*.netrwhist*
See |g:netrw_dirhistmax| for how to control the quantity of history stack
slots. The file ".netrwhist" holds history when netrw (and vim) is not
-active. By default, its stored on the first directory on the user's
+active. By default, it's stored on the first directory on the user's
|'runtimepath'|.
Related Topics:
@@ -3271,7 +3271,7 @@
fun! ExampleUserMapFunc(islocal)
<
-where a:islocal is 1 if its a local-directory system call or 0 when
+where a:islocal is 1 if it's a local-directory system call or 0 when
remote-directory system call.
Use netrw#Expose("varname") to access netrw-internal (script-local)
@@ -3595,7 +3595,7 @@
*netrw-p16*
P16. When editing remote files (ex. :e ftp://hostname/path/file),
- under Windows I get an |E303| message complaining that its unable
+ under Windows I get an |E303| message complaining that it's unable
to open a swap file.
(romainl) It looks like you are starting Vim from a protected
@@ -3649,7 +3649,7 @@
P21. I've made a directory (or file) with an accented character, but
netrw isn't letting me enter that directory/read that file:
- Its likely that the shell or o/s is using a different encoding
+ It's likely that the shell or o/s is using a different encoding
than you have vim (netrw) using. A patch to vim supporting
"systemencoding" may address this issue in the future; for
now, just have netrw use the proper encoding. For example: >