docs: Clean up python, provider, remote_plugin #2056

* "Python" is a proper noun and should be capitalized in prose
* Corrected use of "its/it's"
* Used better preposition to describe something "in" legacy Vim
* Combine fragments into complete sentence

runtime/doc/msgpack_rpc.txt

@@ -60,7 +60,7 @@ There are two ways to obtain API metadata:
    separate compilation step.
 
 Here's a simple way to get human-readable description of the API (requires
-python and the `pyyaml`/`msgpack-python` pip packages):
+Python and the `pyyaml`/`msgpack-python` pip packages):
 >
     nvim --api-info | python -c 'import msgpack, sys, yaml; print yaml.dump(msgpack.unpackb(sys.stdin.read()))' > api.yaml
 
@@ -108,7 +108,7 @@ string 'hello world!' on the current nvim instance:
     nvim = MessagePack::RPC::Client.new(MessagePack::RPC::UNIXTransport.new, ENV['NVIM_LISTEN_ADDRESS'])
     result = nvim.call(:vim_command, 'echo "hello world!"')
 <
-A better way is to use the python REPL with the `neovim` package, where API
+A better way is to use the Python REPL with the `neovim` package, where API
 functions can be called interactively:
 >
     >>> from neovim import attach
@@ -119,7 +119,7 @@ functions can be called interactively:
 4. Implementing new clients				  *msgpack-rpc-clients*
 
 Nvim is still in alpha, so there's no in-depth documentation explaining how to
-properly implement a client library yet. The python client (the pip package
+properly implement a client library yet. The Python client (the pip package
 "neovim") will always be up-to-date with the latest API changes, so its source
 code is the best documentation currently available. There are some guidelines
 however:

runtime/doc/nvim_provider.txt

@@ -10,10 +10,10 @@ First of all, this document is meant to be read by developers interested in
 contributing to the refactoring effort. If you are a normal user or plugin
 developer looking to learn about Nvim |msgpack-rpc| infrastructure for
 implementing plugins in other programming languages, see |external-plugin|.
-For instructions on how to enable python plugins, see |nvim-python|. For
+For instructions on how to enable Python plugins, see |nvim-python|. For
 clipboard, see |nvim-clipboard|.
 
-Instead of doing everything by itself, Nvim aims to simplify it's own
+Instead of doing everything by itself, Nvim aims to simplify its own
 maintenance by delegating as much work as possible to external systems. But
 some Vim components are too tightly coupled and in some cases the refactoring
 work necessary to swap in-house implementations by code that integrates to
@@ -24,18 +24,18 @@ To understand why the provider infrastructure is useful, let us consider two
 examples of integration with external systems that are implemented in Vim and
 are now decoupled from Nvim core as providers:
 
-The first example is clipboard integration: On the original Vim source code,
+The first example is clipboard integration: in the original Vim source code,
 clipboard functions account for more than 1k lines of C source code (and that
-is just on ui.c). All to peform two tasks that are now accomplished with
+is just on ui.c), all to peform two tasks that are now accomplished with
 simple shell commands such as xclip or pbcopy/pbpaste.
 
-The other example is python scripting support: Vim has three files dedicated
+The other example is Python scripting support: Vim has three files dedicated
-to embed the python interpreter: if_python.c, if_python3.c and if_py_both.h.
+to embed the Python interpreter: if_python.c, if_python3.c and if_py_both.h.
-Together these files sum about 9.5k lines of C source code. On Nvim, python
+Together these files sum about 9.5k lines of C source code. On Nvim, Python
 scripting is performed by an external host process that is running 2k sloc
-python program.
+Python program.
 
-In a perfect world, we would implement python and clipboard integration in
+In a perfect world, we would implement Python and clipboard integration in
 pure vimscript and without touching the C code. Unfortunately we can't achieve
 these goals without severly compromising backwards compatibility with Vim.
 Thats where providers comes to rescue.
@@ -61,15 +61,15 @@ The basic idea is that the provider#(name)#Call function should implement
 integration with an external system, because calling shell commands and
 |msgpack-rpc| clients (Nvim only) is easier to do in vimscript.
 
-Now, back to the python example. Instead of modifying vimscript to allow for
+Now, back to the Python example. Instead of modifying vimscript to allow for
 the definition of lowercase functions and commands (for the |:python|,
 |:pyfile|, and |:pydo| commands, and the |pyeval()| function), which would
 break backwards compatibility with Vim, we implemented the
 autoload/provider/python.vim script and the provider#python#Call function
-that is only defined if an external python host is started successfully.
+that is only defined if an external Python host is started successfully.
 
-That works well with the `has('python')` expression (normally used by python
+That works well with the `has('python')` expression (normally used by Python
-plugins) because if the python host isn't installed then the plugin will
+plugins) because if the Python host isn't installed then the plugin will
 "think" it is running in a Vim compiled without |+python| feature.
 
 ==============================================================================

runtime/doc/nvim_python.txt

@@ -12,22 +12,22 @@ Python plugins and scripting in Nvim				  *nvim-python*
 ==============================================================================
 1. Introduction						    *nvim-python-intro*
 
-Through an external python interpreter connected via |msgpack-rpc|, Nvim
+Through an external Python interpreter connected via |msgpack-rpc|, Nvim
 offers some support for the legacy |python-vim| interface. For now only the
 old Vim 7.3 API is supported.
 
 ==============================================================================
 2. Quickstart					       *nvim-python-quickstart*
 
-If you just want to start using Vim python plugins with Nvim quickly, here's a
+If you just want to start using Vim Python plugins with Nvim quickly, here's a
 simple tutorial:
 
-- Make sure python 2.6 or 2.7 is available in your `$PATH`
+- Make sure Python 2.6 or 2.7 is available in your `$PATH`
-- Install the `neovim` python package:
+- Install the `neovim` Python package:
   >
       $ pip install neovim
 <
-Most python plugins created for Vim 7.3 should work after these steps.
+Most Python plugins created for Vim 7.3 should work after these steps.
 
 ==============================================================================
  vim:tw=78:ts=8:noet:ft=help:norl:

runtime/doc/remote_plugin.txt

@@ -42,7 +42,7 @@ startup as fast as possible if many plugins/hosts are installed.
 3. Example					    *remote-plugin-example*
 
 The best way to learn about remote plugins is with an example, so let's see
-what a python plugin looks like. This plugin exports a command, a function and
+what a Python plugin looks like. This plugin exports a command, a function and
 an autocmd. The plugin is called 'Limit', and all it does is limit the number
 of requests made to it. Here's the plugin source code:
 >
@@ -81,7 +81,7 @@ of requests made to it. Here's the plugin source code:
             self.calls += 1
 <
 
-As can be seen, the plugin is implemented using pure python idioms (classes,
+As can be seen, the plugin is implemented using pure Python idioms (classes,
 methods, and decorators), the translation between these language-specific
 idioms to vimscript occurs while the plugin manifest is being generated (see
 below).
@@ -117,7 +117,7 @@ declared command, autocommand, or function is used for the first time.
 
 The manifest generation step is necessary to keep Nvim's startup fast in
 situations where a user has remote plugins with different hosts. For example,
-say a user has three plugins, for python, java and .NET hosts respectively. If
+say a user has three plugins, for Python, java and .NET hosts respectively. If
 we were to load all three plugins at startup, then three language runtimes
 would also be spawned which could take seconds!