| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
Create the msgpack_rpc subdirectory and move all modules that deal with
msgpack-rpc to it. Also merge msgpack_rpc.c into msgpack_rpc/helpers.c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add error type information to `Error`
- Rename `set_api_error` to `api_set_error` for consistency with other api_*
functions/macros.
- Refactor the api_set_error macro to accept formatted strings and error types
- Improve error messages
- Wrap error messages with gettext macro
- Refactor msgpack-rpc serialization to transform Error instances into [type,
message] arrays
- Add error type information to API metadata
- Normalize nvim->client and client->nvim error handling(change
channel_send_call to accept an Error pointer instead of the `errored` boolean
pointer)
- Use macro to initialize Error structures
|
| |
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
| |
- Move helpers that are specific to API types to api/private/helpers.{c,h}
- Include headers with generated declarations
- Delete unused macros
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
There's no need to have integer and string ids, and since we now fully support
msgpack-RPC, support for integer ids was 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).
|
| |
|
|
|
| |
Since that function is not automatically generated, it's best to place it in a
normal C module
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This is required by the msgpack-RPC specification. Also, the
send_call/send_event functions were refactored to accept a variable number of
arguments
|
| | |
|
| |
|
|
|
|
| |
Also changed the default log level to INFO so developers won't end up with big
log files without asking explicitly(DLOG statements were placed in really "hot"
code)
|
| |
|
|
|
|
| |
This is required to handle broadcasting when the first write fails.
Ref: https://github.com/tarruda/neovim/commit/11916b6b595421ce2ece10f7aa40757cc4937c0c#commitcomment-6792287
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is how API dispatching worked before this commit:
- The generated `msgpack_rpc_dispatch` function receives a the `msgpack_packer`
argument.
- The response is incrementally built while validating/calling the API.
- Return values/errors are also packed into the `msgpack_packer` while the
final response is being calculated.
Now the `msgpack_packer` argument is no longer provided, and the
`msgpack_rpc_dispatch` function returns `Object`/`Error` values to
`msgpack_rpc_call`, which will use those values to build the response in a
single pass.
This was done because the new `channel_send_call` function created the
possibility of having recursive API invocations, and this wasn't possible when
sharing a single `msgpack_sbuffer` across call frames(it was shared implicitly
through the `msgpack_packer` instance).
Since we only start to build the response when the necessary information has
been computed, it's now safe to share a single `msgpack_sbuffer` instance
across all channels and API invocations.
Some other changes also had to be performed:
- Handling of the metadata discover was moved to `msgpack_rpc_call`
- Expose more types as subtypes of `Object`, this was required to forward the
return value from `msgpack_rpc_dispatch` to `msgpack_rpc_call`
- Added more helper macros for casting API types to `Object`
any
|
| |
|
|
|
| |
Move validation/conversion functions and to msgpack_rpc_helpers to separate
those from the functions that are used from the channel module
|
| |
|
|
|
|
|
|
|
|
| |
- Generalize some argument names(event type -> event name,
event data -> event arg)
- Rename serialize_event to serialize_message
- Rename msgpack_rpc_notification to msgpack_rpc_message
- Extract the message type out of msgpack_rpc_message
- Add 'id' parameter to msgpack_rpc_message/serialize_message to create messages
that are not notifications
|
| |
|
|
|
|
|
|
|
| |
There seems to be no way to deal with failures when calling
`msgpack_unpacker_next`, so this reimplements that function as
`msgpack_rpc_unpack`, which has an additional result for detecting failures.
On top of that, we make use of the new function to properly return msgpack-rpc
errors when something bad happens.
|
| |
|
|
|
|
|
| |
It's a 1-byte loss of memory but it allows us to skip copying and
NULL-terminating strings when interacting with vim functions that accept C
strings. This lowers the pressure on the allocator and saves lines of code
(no more dup/free pairs).
|
| |
|
|
|
| |
This function can be used to send arbitrary objects via the API channel back to
connected clients, identified by channel id.
|
| |
|
|
|
| |
This refactors msgapck_rpc_{dipatch,call} to receive the channel id as
argument. Now the discovery request returns the [id, metadata] array.
|
| |
|
|
|
|
|
|
|
| |
When receiving strings *from* msgpack, we don't need to duplicate/free since
the data only lives in the msgpack parse buffer until the end of the call.
But in order to reuse `msgpack_rpc_free_object` when sending event data(which is
sent *to* msgpack), Strings must be freed, which means they must also be
allocated separately.
|
| |
|
|
|
|
|
| |
- Define specialized arrays for each remote object type
- Implement msgpack_rpc functions for dealing with the new types
- Refactor all functions dealing with buffers, windows and tabpages to
return/accept handles instead of list indexes.
|
| | |
|
| |
|
|
|
| |
- Add macros supporting typed arrays in the remote API
- Refactor StringArray-related functions on top of the new macros
|
| |
|
|
|
| |
- Extract remote types definitions into a macro
- Extract msgpack_rpc helper functions for remote types into a macro
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Instead of exposing native C types to a public API that can be consumed by other
platforms, we are now using the following translation:
int64_t -> Integer
double -> Float
bool -> Boolean
|
| |
|
|
|
|
|
|
|
| |
This should make the API simpler, and int64_t is enough to represent any integer
value we might need.
Range checks should be done inside the API functions, that way we can modify the
types of the actual fields/variables modified by the API without changes to the
API prototypes.
|
| |
|
|
| |
Prepend 'nvim/' in all project-local (non-system) includes.
|
| |
|
|
|
|
|
|
|
|
| |
Problem: Some newly introduced files used includes relative to the
current file, both of the form `include "../XXX.h"` and
`include "XXX.h"`.
Preferred form is relative to include root (src/ in our case).
Solution: Change includes to preferred form.
Note: This is also done to ease next commit (prepend 'nvim/ to all
project-local includes).
|
|
|
Move files from src/ to src/nvim/.
- src/nvim/ becomes the new root dir for nvim executable sources.
- src/libnvim/ is planned to become root dir of the neovim library.
|
