1 files changed, 74 insertions, 0 deletions
diff --git a/runtime/doc/provider.txt b/runtime/doc/provider.txt
new file mode 100644
index 0000000000..c139105f28
--- /dev/null
+++ b/runtime/doc/provider.txt
@@ -0,0 +1,74 @@
+*provider.txt*								{Nvim}
+
+
+		 NVIM REFERENCE MANUAL    by Thiago de Arruda
+
+
+Nvim provider infrastructure					    *provider*
+
+This document is for developers. If you are a normal user or plugin developer
+looking to learn about Nvim |rpc| for implementing plugins in other
+programming languages, see |remote-plugin|. For instructions on how to enable
+Python plugins, see |nvim-python|. For clipboard, see |clipboard|.
+
+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
+other systems is too great. Nvim provider infrastructure is a facility that
+aims to make this task simpler.
+
+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: 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 perform 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 to
+embedding 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
+scripting is performed by an external host process that is running 2k sloc
+Python program.
+
+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 severely compromising backwards compatibility with Vim.
+That's where providers come to the rescue.
+
+In essence, this infrastructure is a simple framework that simplifies the task
+of calling vimscript from C code, making it simpler to rewrite C functions that
+interact with external systems in pure vimscript. It is composed of two
+functions in eval.c:
+
+- eval_call_provider(name, method, arguments): Call a provider(name) method
+  with arguments
+- eval_has_provider(name): Checks if a provider is implemented
+
+What these functions do is simple:
+
+- eval_call_provider will call the provider#(name)#Call function passing in
+  the method and arguments.
+- eval_has_provider will return true if the provider#(name)#Call function is
+  implemented, and is called by the "has" vimscript function to check if
+  features are available.
+
+The basic idea is that the provider#(name)#Call function should implement
+integration with an external system, because calling shell commands and |rpc|
+clients (Nvim only) is easier to do in vimscript.
+
+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 works well with the `has('python')` expression (normally used by Python
+plugins) because if the Python host isn't installed then the plugin will
+"think" it is running in a Vim compiled without |+python| feature.
+
+==============================================================================
+ vim:tw=78:ts=8:noet:ft=help:norl: