How to develop Nvim, explanation of modules and subsystems

The top of each major module has (or should have) an overview in a comment atthe top of its file. The purpose of this document is to give:

1. an overview of how it all fits together2. how-to guides for common tasks such as:

Usekvec.h for most lists. When you absolutely need a linked list, uselib/queue_defs.h which defines an "intrusive" linked list.

The source files most directly involved with UI events are:1.src/nvim/ui.*: calls handler functions of registered UI structs (independent from msgpack-rpc)2.src/nvim/api/ui.*: forwards messages over msgpack-rpc to remote UIs.

UI events are defined insrc/nvim/api/ui_events.in.h , this file is notcompiled directly, rather it parsed bysrc/nvim/generators/gen_api_ui_events.lua which autogenerates wrapperfunctions used by the source files above. It also generates metadataaccessible asapi_info().ui_events.

See commit d3a8e9217f39c59dd7762bd22a76b8bd03ca85ff for an example of addinga new UI event.

UI events are deferred to UIs, which implies a deepcopy of the UI event data.

Remember to bump NVIM_API_LEVEL if it wasn't already during this developmentcycle.

Other references:

dev-api-fast
API functions and Vimscript "eval" functions may be marked asapi-fast whichmeans they are safe to call in Lua callbacks and other scenarios. A functionsCANNOT be marked as "fast" if could triggeros_breakcheck(), which may"yield" the current execution and start a new execution of code not expectingthis:

In practice, this means any code that could triggeros_breakcheck() cannotbe "fast". For example, commit 3940c435e405 fixed such a bug withnvim__get_runtime by explicitly disallowingos_breakcheck() via theEW_NOBREAK flag.

Common examples of non-fast code: regexp matching, wildcard expansion,expression evaluation.