| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
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.
|
