Adapt gendeclarations.lua/msgpack-gen.lua to allow the `ArrayOf(...)` and
`DictionaryOf(...)` types in function headers. These are simple macros that
expand to Array and Dictionary respectively, but the information is kept in the
metadata object, which is useful for building clients in statically typed
languages.
Instead of building all metadata from msgpack-gen.lua, we now merge the
generated part with manual information(such as types and features). The metadata
is accessible through the api method `vim_get_api_info`.
This was done to simplify the generator while also increasing flexibility(by
being able to add more metadata)
- Providers for features are now registered as a unit. For example, instead of
calling `register_provider("clipboard_get")` and
`register_provider("clipboard_set")`, clients call
`register_provider("clipboard")` and nvim will assume it implements all
methods of the "clipboard" feature
- Bootstrapping code was removed. With the `api_spawn` function exposed to
vimscript, it's no longer necessary and will be handled by plugins
distributed with nvim.
- Now the `has` function will return true if there's a live channel that
has registered as a provider for the feature.
- 'initpython'/'initclipboard' options were removed
- A new API function was exposed: `vim_discover_features` which returns an
object with information about pluggable features such as 'python' or
'clipboard'
Enhance msgpack-gen.lua to extract custom api type codes from the ObjectType
enum in api/private/defs.h. The type information is made available from the api
metadata and clients can use to correctly serialize/deserialize these types
using msgpack EXT type.
Specialized array types(BufferArray, WindowArray, etc) were added to the API for
two main reasons:
- msgpack used to lack a way of serializing appliaction-specific types and there
was no obvious way of making an API function accept/return arrays of custom
objects such as buffers(which are represented as integers, so clients didn't
have a way to distinguish from normal numbers)
- Let clients in statically-typed languages that support generics have a better
typed API
With msgpack 2.0 EXT type the first item is no longer a factor and this commit
starts by removing the specialized array types. The second item will be
addressed in the future by making the API metadata return extra useful
information for statically-typed languages.
The `msgpack_rpc_unpack` function was created to work around a deficiency in the
msgpack unpack API, which did not let the caller know if parsing failed due to
needing more data or to invalid input. The deficiency does not exist in the
latest version of `msgpack_unpacker_next`, so it can safely be removed.
A new method is now exposed via msgpack-rpc: "get_api_metadata". This method has
the same job as the old method '0', it returns an object with API metadata for
use by generators.
There's one difference in the return value though: instead of returning a
string containing another serialized msgpack document, the metadata object is
returned directly(a separate deserialization step by clients is not required).
Use Map(String, rpc_method_handler_fn) for storing/retrieving rpc method
handlers in msgpack_rpc_init and msgpack_rpc_dispatch.
Also refactor serialization/validation functions in the
msgpack_rpc.c/msgpack_rpc_helpers.c modules to accept the new STR and BIN types.
Using msgpack v5 will let nvim be more compatible with msgpack libraries for
other platforms.
This also replaces "raw" references by "bin" which is the new name for msgpack
binary data type
Problem: When there are matches to highlight the whole window is redrawn,
which is slow.
Solution: Only redraw everything when lines were inserted or deleted.
Reset b_mod_xlines when needed. (Alexey Radkov)
https://code.google.com/p/vim/source/detail?r=v7-4-349
