handle |nvim_error_event| notifications, which will be sent
  if an async request to nvim was rejected or caused an error.

Package Naming ~

API client packages should NOT be named something ambiguous like "neovim" or
"python-client".  Use "nvim" as a prefix/suffix to some other identifier
following ecosystem conventions.

For example, Python packages tend to have "py" in the name, so "pynvim" is
a good name: it's idiomatic and unambiguous. If the package is named "neovim",
it confuses users, and complicates documentation and discussions.

Examples of API-client package names:
- ✅ OK: nvim-racket
- ✅ OK: pynvim
- ❌ NO: python-client
- ❌ NO: neovim_

API client implementation guidelines ~

- Separate the transport layer from the rest of the library. |rpc-connecting|
- Use a MessagePack library that implements at least version 5 of the
  MessagePack spec, which supports the BIN and EXT types used by Nvim.
- Use a single-threaded event loop library/pattern.
- Use a fiber/coroutine library for the language being used for implementing
  a client. These greatly simplify concurrency and allow the library to
  expose a blocking API on top of a non-blocking event loop without the
  complexity that comes with preemptive multitasking.
- Don't assume anything about the order of responses to RPC requests.
- Clients should expect requests, which must be handled immediately because
  Nvim is blocked while waiting for the client response.
- Clients should expect notifications, but these can be handled "ASAP" (rather
  than immediately) because they won't block Nvim.
- For C/C++ projects, consider libmpack instead of the msgpack.org library.
    https://github.com/libmpack/libmpack/
  libmpack is small (no dependencies, can inline into your C/C++ project) and
  efficient (no allocations). It also implements msgpack-RPC, the protocol
  required by Nvim.
    https://github.com/msgpack-rpc/msgpack-rpc


EXTERNAL UI                                             *dev-ui*

External UIs should be aware of the |api-contract|. In particular, future
versions of Nvim may add new items to existing events. The API is strongly
backwards-compatible, but clients must not break if new (optional) fields are
added to existing events.

Standard Features ~

External UIs are expected to implement these common features:

- Call |nvim_set_client_info()| after connecting, so users and plugins can
  detect the UI by handling the |ChanInfo| event. This avoids the need for
  special variables and UI-specific config files (gvimrc, macvimrc, …).
- Cursor style (shape, color) should conform to the 'guicursor' properties
  delivered with the mode_info_set UI event.
- Send the ALT/META ("Option" on macOS) key as a |<M-| chord.
- Send the "super" key (Windows key, Apple key) as a |<D-| chord.
- Avoid mappings that conflict with the Nvim keymap-space; GUIs have many new
  chords (<C-,> <C-Enter> <C-S-x> <D-x>) and patterns ("shift shift") that do
  not potentially conflict with Nvim defaults, plugins, etc.
- Consider the "option_set" |ui-global| event as a hint for other GUI
  behaviors. Various UI-related options ('guifont', 'ambiwidth', …) are
  published in this event. See also "mouse_on", "mouse_off".
- UIs generally should NOT set |$NVIM_APPNAME| (unless explicitly requested by
  the user).
- Support the text decorations/attributes given by |ui-event-hl_attr_define|.
  The "url" attr should be presented as a clickable hyperlink.
- Handle the "restart" UI event so that |:restart| works.


 vim:tw=78:ts=8:sw=4:et:ft=help:norl: