win:          Window

Do NOT use these deprecated nouns:
    - buffer        Use "buf" instead
    - callback      Use on_foo instead
    - command       Use "cmd" instead
    - window        Use "win" instead

                                                        *dev-name-events*
Use the "on_" prefix to name event-handling callbacks and also the interface for
"registering" such handlers (on_key). The dual nature is acceptable to avoid
a confused collection of naming conventions for these related concepts.

Editor |events| (autocommands) are historically named like: >
    {Noun}{Event}

Use this format to name API (RPC) events: >
    nvim_{noun}_{event-name}_event

Example: >
    nvim_buf_changedtick_event
<
                                                        *dev-api-name*
Use this format to name new RPC |API| functions: >
    nvim_{topic}_{verb}_{arbitrary-qualifiers}

Do not add new nvim_buf/nvim_win/nvim_tabpage APIs, unless you are certain the
concept will NEVER be applied to more than one "scope". That is, {topic}
should be the TOPIC ("ns", "extmark", "option", …) that acts on the scope(s)
(buf/win/tabpage/global), it should NOT be the scope. Instead the scope should
be a parameter (typically manifest as mutually-exclusive buf/win/… flags like
|nvim_get_option_value()|, or less commonly as a `scope: string` field like
|nvim_get_option_info2()|).

- Example: `nvim_get_keymap('v')` operates in a global context (first
  parameter is not a Buffer). The "get" verb indicates that it gets anything
  matching the given filter parameter. A "list" verb is unnecessary because
  `nvim_get_keymap('')` (empty filter) returns all items.
- Example: `nvim_buf_del_mark` acts on a `Buffer` object (the first parameter)
  and uses the "del" {verb}.

                                                        *dev-namespace-name*
Use namespace names like `nvim.foo.bar`: >
    vim.api.nvim_create_namespace('nvim.lsp.codelens')
<

                                                        *dev-augroup-name*
Use autocommand group names like `nvim.foo.bar`: >
    vim.api.nvim_create_augroup('nvim.treesitter.dev')
<

INTERFACE PATTERNS                                      *dev-api-patterns*

Prefer adding a single `nvim_{topic}_{verb}_…` interface for a given topic.

Example: >

    nvim_ns_add(
      ns_id: int,
      filter: {
        handle: integer (buf/win/tabpage id)
        scope: "global" | "win" | "buf" | "tabpage"
      }
    ): { ok: boolean }

    nvim_ns_get(
      ns_id: int,
      filter: {
        handle: integer (buf/win/tabpage id)
        scope: "global" | "win" | "buf" | "tabpage"
      }
    ): { ids: int[] }

    nvim_ns_del(
      ns_id: int,
      filter: {
        handle: integer (buf/win/tabpage id)
        scope: "global" | "win" | "buf" | "tabpage"
      }
    ): { ok: boolean }


Anti-Example:

Creating separate `nvim_xx`, `nvim_buf_xx`, `nvim_win_xx`, and
`nvim_tabpage_xx`, functions all for the same `xx` topic, requires 4x the
amount of documentation, tests, boilerplate, and interfaces, which users must
comprehend, maintainers must maintain, etc. Thus the following is NOT
recommended (compare these 12(!) functions to the above 3 functions): >

    nvim_add_ns(…)
    nvim_buf_add_ns(…)
    nvim_win_add_ns(…)
    nvim_tabpage_add_ns(…)
    nvim_del_ns(…)
    nvim_buf_del_ns(…)
    nvim_win_del_ns(…)
    nvim_tabpage_del_ns(…)
    nvim_get_ns(…)
    nvim_buf_get_ns(…)
    nvim_win_get_ns(…)
    nvim_tabpage_get_ns(…)

API-CLIENT                                              *dev-api-client*

                                                        *api-client*
API clients wrap the Nvim |API| to provide idiomatic "SDKs" for their
respective platforms (see |jargon|). You can build a new API client for your
favorite platform or programming language.

List of API clients:
    https://github.com/neovim/neovim/wiki/Related-projects#api-clients

                                                        *node-client* *pynvim*
These