|--api-info|. Useful for statically-compiled clients.
     Example (requires Python "pyyaml" and "msgpack-python" modules): >
     nvim --api-info | python -c 'import msgpack, sys, yaml; yaml.dump(msgpack.unpackb(sys.stdin.buffer.read()), sys.stdout)'
<
  3. Use the |api_info()| Vimscript function. >vim
     :lua vim.print(vim.fn.api_info())
<     Example using |filter()| to exclude non-deprecated API functions: >vim
     :new|put =map(filter(api_info().functions, '!has_key(v:val,''deprecated_since'')'), 'v:val.name')

==============================================================================
API contract                                                     *api-contract*

The Nvim API is composed of functions and events.

- Clients call functions like those described at |api-global|.
- Clients can subscribe to |ui-events|, |api-buffer-updates|, etc.
- API function names are prefixed with "nvim_".
- API event names are prefixed with "nvim_" and suffixed with "_event".

As Nvim evolves the API may change in compliance with this CONTRACT:

- New functions and events may be added.
  - Any such extensions are OPTIONAL: old clients may ignore them.
- Function signatures will NOT CHANGE (after release).
  - Functions introduced in the development (unreleased) version MAY CHANGE.
    (Clients can dynamically check `api_prerelease`, etc. |api-metadata|)
- Event parameters will not be removed or reordered (after release).
- Events may be EXTENDED: new parameters may be added.
- New items may be ADDED to map/list parameters/results of functions and
  events.
  - Any such new items are OPTIONAL: old clients may ignore them.
  - Existing items will not be removed (after release).
- Deprecated functions will not be removed until Nvim version 2.0

"Private" interfaces are NOT covered by this contract:

- Undocumented (not in :help) functions or events of any kind
- nvim__x ("double underscore") functions

The idea is "versionless evolution", in the words of Rich Hickey:
- Relaxing a requirement should be a compatible change.
- Strengthening a promise should be a compatible change.

==============================================================================
Global events                                               *api-global-events*

When a client invokes an API request as an async notification, it is not
possible for Nvim to send an error response. Instead, in case of error, the
following notification will be sent to the client:

                                                             *nvim_error_event*
nvim_error_event[{type}, {message}]

{type} is a numeric id as defined by `api_info().error_types`, and {message} is
a string with the error message.

==============================================================================
Buffer update events                                    *api-buffer-updates*

API clients can "attach" to Nvim buffers to subscribe to buffer update events.
This is similar to |TextChanged| but more powerful and granular.

Call |nvim_buf_attach()| to receive these events on the channel:

                                                        *nvim_buf_lines_event*
nvim_buf_lines_event[{buf}, {changedtick}, {firstline}, {lastline}, {linedata}, {more}]

    When the buffer text between {firstline} and {lastline} (end-exclusive,
    zero-indexed) were changed to the new text in the {linedata} list. The
    granularity is a line, i.e. if a single character is changed in the
    editor, the entire line is sent.

    When {changedtick} is |v:null| this means the screen lines (display)
    changed but not the buffer contents. {linedata} contains the changed
    screen lines. This happens when 'inccommand' shows a buffer preview.

    Properties: ~
        {buf} API buffer handle (buffer number)

        {changedtick} value of |b:changedtick| for the buffer. If you send an
        API command back to nvim you can check the value of |b:changedtick| as
        part of your request to ensure that no other changes