("families"), and reduces cognitive
burden. Discoverability encourages code re-use and likewise avoids redundant,
overlapping mechanisms, which reduces code surface-area, and thereby minimizes
bugs...

Naming conventions ~

In general, look for precedent when choosing a name, that is, look at existing
(non-deprecated) functions. In particular, see below...

                                                        *dev-name-common*
Use existing common {verb} names (actions) if possible:
    - add:          Appends or inserts into a collection
    - attach:       Listens to something to get events from it (TODO: rename to "on"?)
    - call:         Calls a function
    - cancel:       Cancels or dismisses an event or interaction, typically
                    user-initiated and without error. (Compare "abort", which
                    cancels and signals error/failure.)
    - clear:        Clears state but does not destroy the container
    - create:       Creates a new (non-trivial) thing (TODO: rename to "def"?)
    - del:          Deletes a thing (or group of things)
    - detach:       Dispose attached listener (TODO: rename to "un"?)
    - enable:       Enables/disables functionality. Signature should be
                    `enable(enable?:boolean, filter?:table)`.
    - eval:         Evaluates an expression
    - exec:         Executes code, may return a result
    - fmt:          Formats
    - get:          Gets things. Two variants (overloads):
                    1. `get<T>(id: int): T` returns one item.
                    2. `get<T>(filter: dict): T[]` returns a list.
    - inspect:      Presents a high-level, often interactive, view
    - is_enabled:   Checks if functionality is enabled.
    - open:         Opens something (a buffer, window, …)
    - parse:        Parses something into a structured form
    - set:          Sets a thing (or group of things)
    - start:        Spin up a long-lived process. Prefer "enable" except when
                    "start" is obviously more appropriate.
    - stop:         Inverse of "start". Teardown a long-lived process.
    - try_{verb}:   Best-effort operation, failure returns null or error obj

Do NOT use these deprecated verbs:
    - disable:      Prefer `enable(enable: boolean)`.
    - exit:         Prefer "cancel" (or "stop" if appropriate).
    - is_disabled:  Prefer `is_enabled()`.
    - list:         Redundant with "get"
    - notify:       Redundant with "print", "echo"
    - show:         Redundant with "print", "echo"
    - toggle:       Prefer `enable(not is_enabled())`.

Use consistent names for {topic} in API functions: buffer is called "buf"
everywhere, not "buffer" in some places and "buf" in others.
    - buf:          Buffer
    - chan:         |channel|
    - cmd:          Command
    - cmdline:      Command-line UI or input
    - fn:           Function
    - hl:           Highlight
    - pos:          Position
    - proc:         System process
    - tabpage:      Tabpage
    - 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