The os_system function uses a write callback to close the input stream when the
write completes, but this causes a memory error because the callback is invoked
right before the stream is freed by the caller.
This fixes the problem by removing the callback set by os_system. Instead, it
calls job_close_in immediately after writing(the stream will only close after
the write completes). The 'pending' parameter was also removed from the
'write_cb' as it should be hidden by the wstream module.
While the `wstream_set_write_cb` and `job_write_cb` are no longer used, they
will remain in the codebase for future use.
- 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)
- 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'
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
This was causing a segfault(reported in #1125) because channels are already
closed by `parse_msgpack` when the connection ends. Also fix the RPC stack
overflow error message
It's analogous to rstream_set_file but only supports pipes(Support for regular
files may be added later). This function was added to support creating API
channels via stdout.
* With the changes in commit
"events: Refactor how event deferral is handled"
(2e4ea29d2c) the function argument
'defer' of 'job_start' and member variable 'defer' of 'struct job'
can be removed.
* Update/Fix the documentation for function 'job_start'.
Not necessary, as discussed in #980.
From the libuv mailing list:
https://groups.google.com/forum/#!topic/libuv/OD38PeGeVgQ
E.g. this could happen (red: on Windows):
> > alloc_cb(handle1);
> > alloc_cb(handle2);
> > read_cb(handle1);
> > read_cb(handle2);
But this couldn't:
> > alloc_cb(handle1);
> > alloc_cb(handle1);
> > read_cb(handle1);
> > read_cb(handle1);
Because each stream has a 1-to-1 correspondance with a libuv handle. The
code removed was never executed.
Closes#980.
It used to be 1024 bytes, which is very tiny and slows down some operations
(imaging `cat`-ing a large file). Benchmarks show a large speedup for such
cases. ref #978.
For modern systems 0xFFFF bytes (65535 B = 64 KB = 0.0625 MB) per job
shouldn't be a big problem.
With the goal to support pipe-only system() calls.
Notes on the second (vim) argument to f_system() (i.e.: redirected input)
and its implications:
- When calling system('cat -', ['some', 'list']), vanilla vim (before a
recent patch that added support for passing lists) just passes an empty
file to the process. This is the same as immediately closing the pipe,
which os_system does when no input is given. If we wouldn't close the
pipe, the process will linger forever (as is the case with `cat -`).
As of now, it's not allowed to pass a non-NULL pointer as the `output`
parameter. In other words, it's not possible to signal disinterst in the
process output. That may change in the future.
