remote_plugin.txt 6.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142
  1. *remote_plugin.txt* Nvim
  2. NVIM REFERENCE MANUAL by Thiago de Arruda
  3. Nvim support for remote plugins *remote-plugin*
  4. Type |gO| to see the table of contents.
  5. ==============================================================================
  6. 1. Introduction *remote-plugin-intro*
  7. Extensibility is a primary goal of Nvim. Any programming language may be used
  8. to extend Nvim without changes to Nvim itself. This is achieved with remote
  9. plugins, coprocesses that have a direct communication channel (via |RPC|) with
  10. the Nvim process.
  11. Even though these plugins run in separate processes they can call, be called,
  12. and receive events just as if the plugin's code were executed in the main
  13. process.
  14. ==============================================================================
  15. 2. Plugin hosts *remote-plugin-hosts*
  16. While plugins can be implemented as arbitrary programs that communicate
  17. directly with the high-level Nvim API and are called via |rpcrequest()| and
  18. |rpcnotify()|, that is not the best approach. Instead, developers should first
  19. check whether a plugin host is available for their chosen programming language.
  20. Plugin hosts are programs that provide a high-level environment for plugins,
  21. taking care of most boilerplate involved in defining commands, autocmds, and
  22. functions that are implemented over |RPC| connections. Hosts are loaded only
  23. when one of their registered plugins require it, keeping Nvim's startup as
  24. fast as possible, even if many plugins/hosts are installed.
  25. ==============================================================================
  26. 3. Example *remote-plugin-example*
  27. The best way to learn about remote plugins is with an example, so let's see
  28. what a Python plugin looks like. This plugin exports a command, a function, and
  29. an autocmd. The plugin is called 'Limit', and all it does is limit the number
  30. of requests made to it. Here's the plugin source code:
  31. >
  32. import pynvim
  33. @pynvim.plugin
  34. class Limit(object):
  35. def __init__(self, vim):
  36. self.vim = vim
  37. self.calls = 0
  38. @pynvim.command('Cmd', range='', nargs='*', sync=True)
  39. def command_handler(self, args, range):
  40. self._increment_calls()
  41. self.vim.current.line = (
  42. 'Command: Called %d times, args: %s, range: %s' % (self.calls,
  43. args,
  44. range))
  45. @pynvim.autocmd('BufEnter', pattern='*.py', eval='expand("<afile>")',
  46. sync=True)
  47. def autocmd_handler(self, filename):
  48. self._increment_calls()
  49. self.vim.current.line = (
  50. 'Autocmd: Called %s times, file: %s' % (self.calls, filename))
  51. @pynvim.function('Func')
  52. def function_handler(self, args):
  53. self._increment_calls()
  54. self.vim.current.line = (
  55. 'Function: Called %d times, args: %s' % (self.calls, args))
  56. def _increment_calls(self):
  57. if self.calls == 5:
  58. raise Exception('Too many calls!')
  59. self.calls += 1
  60. <
  61. As can be seen, the plugin is implemented using idiomatic Python (classes,
  62. methods, and decorators). The translation between these language-specific
  63. idioms to Vimscript occurs while the plugin manifest is being generated (see
  64. the next section).
  65. Notice that the exported command and autocmd are defined with the "sync" flag,
  66. which affects how Nvim calls the plugin: with "sync" the |rpcrequest()|
  67. function is used, which will block Nvim until the handler function returns a
  68. value. Without the "sync" flag, the call is made using a fire and forget
  69. approach with |rpcnotify()|, meaning return values or exceptions raised in the
  70. handler function are ignored.
  71. To test the above plugin, it must be saved in "rplugin/python" in a
  72. 'runtimepath' directory (~/.config/nvim/rplugin/python/limit.py for example).
  73. Then, the remote plugin manifest must be generated with
  74. |:UpdateRemotePlugins|.
  75. ==============================================================================
  76. 4. Remote plugin manifest *remote-plugin-manifest*
  77. *:UpdateRemotePlugins*
  78. Just installing remote plugins to "rplugin/{host}" isn't enough for them to be
  79. automatically loaded when required. You must execute |:UpdateRemotePlugins|
  80. every time a remote plugin is installed, updated, or deleted.
  81. |:UpdateRemotePlugins| generates the remote plugin manifest, a special
  82. Vimscript file containing declarations for all Vimscript entities
  83. (commands/autocommands/functions) defined by all remote plugins, with each
  84. entity associated with the host and plugin path.
  85. Manifest declarations are just calls to the `remote#host#RegisterPlugin`
  86. function, which takes care of bootstrapping the host as soon as the declared
  87. command, autocommand, or function is used for the first time.
  88. The manifest generation step is necessary to keep Nvim's startup fast in
  89. situations where a user has remote plugins with different hosts. For example,
  90. say a user has three plugins, for Python, Java and .NET hosts respectively. If
  91. we were to load all three plugins at startup, then three language runtimes
  92. would also be spawned, which could take seconds!
  93. With the manifest, each host will only be loaded when required. Continuing with
  94. the example, say the Java plugin is a semantic completion engine for Java code.
  95. If it defines the autocommand "BufEnter *.java", then the Java host is spawned
  96. only when Nvim loads a buffer matching "*.java".
  97. If the explicit call to |:UpdateRemotePlugins| seems inconvenient, try to see
  98. it like this: It's a way to provide IDE capabilities in Nvim while still
  99. keeping it fast and lightweight for general use. It's also analogous to the
  100. |:helptags| command.
  101. *$NVIM_RPLUGIN_MANIFEST*
  102. Unless $NVIM_RPLUGIN_MANIFEST is set the manifest will be written to a file
  103. named `rplugin.vim` at:
  104. Unix ~
  105. $XDG_DATA_HOME/nvim/ or ~/.local/share/nvim/
  106. Windows ~
  107. $LOCALAPPDATA/nvim/ or ~/AppData/Local/nvim/
  108. ==============================================================================
  109. vim:tw=78:ts=8:noet:ft=help:norl: