calls!')
            self.calls += 1
<

As can be seen, the plugin is implemented using idiomatic Python (classes,
methods, and decorators). The translation between these language-specific
idioms to Vimscript occurs while the plugin manifest is being generated (see
the next section).

Notice that the exported command and autocmd are defined with the "sync" flag,
which affects how Nvim calls the plugin: with "sync" the |rpcrequest()|
function is used, which will block Nvim until the handler function returns a
value. Without the "sync" flag, the call is made using a fire and forget
approach with |rpcnotify()|, meaning return values or exceptions raised in the
handler function are ignored.

To test the above plugin, it must be saved in "rplugin/python" in a
'runtimepath' directory (~/.config/nvim/rplugin/python/limit.py for example).
Then, the remote plugin manifest must be generated with
|:UpdateRemotePlugins|.

==============================================================================
4. Remote plugin manifest			    *remote-plugin-manifest*
						      *:UpdateRemotePlugins*

Just installing remote plugins to "rplugin/{host}" isn't enough for them to be
automatically loaded when required. You must execute |:UpdateRemotePlugins|
every time a remote plugin is installed, updated, or deleted.

|:UpdateRemotePlugins| generates the remote plugin manifest, a special
Vimscript file containing declarations for all Vimscript entities
(commands/autocommands/functions) defined by all remote plugins, with each
entity associated with the host and plugin path.

Manifest declarations are just calls to the `remote#host#RegisterPlugin`
function, which takes care of bootstrapping the host as soon as the 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
we were to load all three plugins at startup, then three language runtimes
would also be spawned, which could take seconds!

With the manifest, each host will only be loaded when required. Continuing with
the example, say the Java plugin is a semantic completion engine for Java code.
If it defines the autocommand `BufEnter *.java`, then the Java host is spawned
only when Nvim loads a buffer matching "*.java".

If the explicit call to |:UpdateRemotePlugins| seems inconvenient, try to see
it like this: It's a way to provide IDE capabilities in Nvim while still
keeping it fast and lightweight for general use. It's also analogous to the
|:helptags| command.

						*$NVIM_RPLUGIN_MANIFEST*
Unless $NVIM_RPLUGIN_MANIFEST is set the manifest will be written to a file
named `rplugin.vim` at:

	Unix ~
	  $XDG_DATA_HOME/nvim/ or ~/.local/share/nvim/

	Windows ~
	  $LOCALAPPDATA/nvim/ or ~/AppData/Local/nvim/

 vim:tw=78:ts=8:noet:ft=help:norl: