*develop.txt*          Nvim


                            NVIM REFERENCE MANUAL


Development of Nvim                                     *development* *dev*

This reference describes design constraints and guidelines, for developing
Nvim applications or Nvim itself. See |dev-arch| for discussion of Nvim's
architecture and internal concepts.

Nvim is free and open source.  Everybody is encouraged to contribute.
    https://github.com/neovim/neovim/blob/master/CONTRIBUTING.md

                                      Type |gO| to see the table of contents.

==============================================================================
Design goals                                            *design-goals*

Most important things come first (roughly).  Some items conflict; this is
intentional.  A balance must be found.


NVIM IS... IMPROVED                                     *design-improved*

The Neo bits of Nvim should make it a better Vim, without becoming a
completely different editor.
- In matters of taste, prefer Vim/Unix tradition. If there is no relevant
  Vim/Unix tradition, consider the "common case".
- There is no limit to the features that can be added.  Select new features
  based on (1) what users ask for, (2) how much effort it takes to implement
  and (3) someone actually implementing it.
- Backwards compatibility is a feature.  The RPC API in particular should
  never break.


NVIM IS... WELL DOCUMENTED                              *design-documented*

- A feature that isn't documented is a useless feature.  A patch for a new
  feature must include the documentation.
- Documentation should be comprehensive and understandable.  Use examples.
- Don't make the text unnecessarily long.  Less documentation means that an
  item is easier to find.


NVIM IS... FAST AND SMALL                               *design-speed-size*

Keep Nvim small and fast. This directly affects versatility and usability.
- Computers are becoming faster and bigger each year.  Vim can grow too, but
  no faster than computers are growing.  Keep Vim usable on older systems.
- Many users start Vim from a shell very often.  Startup time must be short.
- Commands must work efficiently.  The time they consume must be as small as
  possible.  Useful commands may take longer.
- Don't forget that some people use Vim over a slow connection.  Minimize the
  communication overhead.
- Vim is a component among other components.  Don't turn it into a massive
  application, but have it work well together with other programs
  ("composability").


NVIM IS... MAINTAINABLE                                 *design-maintain*

- The source code should not become a mess.  It should be reliable code.
- Use comments in a useful way!  Quoting the function name and argument names
  is NOT useful.  Do explain what they are for.
- Porting to another platform should be made easy, without having to change
  too much platform-independent code.
- Use the object-oriented spirit: Put data and code together.  Minimize the
  knowledge spread to other parts of the code.


NVIM IS... NOT                                          *design-not*

Nvim is not an operating system; instead it should be composed with other
tools or hosted as a component. Marvim once said: "Unlike Emacs, Nvim does not
include the kitchen sink... but it's good for plumbing."


==============================================================================
Developer guidelines                                    *dev-guidelines*


PROVIDERS                                               *dev-provider*

A primary goal of Nvim is to allow extension of the editor without special
knowledge in the core.  Some core functions are delegated to "providers"
implemented as external scripts.

Examples:

1. In the Vim source code, clipboard logic accounts for more than 1k lines of
   C source code (ui.c), to perform two tasks that are now accomplished with
   shell commands such as xclip or pbcopy/pbpaste.

2. Python scripting support: