| Commit message (Collapse) | Author | Age |
| ... | |
| |
|
|
|
|
|
|
| |
If we fail to bind to the server address, do not try and listen lest the
reported error always be "invalid argument".
Also, return whether or not we errored from server_init() in case we
want to respond differently in the future.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Problem: It is not easy to get the full path of a command.
Solution: Add the exepath() function.
https://code.google.com/p/vim/source/detail?r=5ab2946f7ce560985830fbc3c453bb0f7a01f385
|
| | |
|
| |
|
|
|
| |
To follow the pattern of using NVIM for technical descriptions, it was renamed
to NVIM_LISTEN_ADDRESS
|
| |
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
| |
This function is used to report errors caused by remote functions called by
channel_send_call
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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'
|
| |
|
|
| |
Simple function for closing a channel by id
|
| |
|
|
| |
The current code was leading to an invalid free when the wstream was closed
|
| | |
|
| |
|
|
|
|
| |
- Move helpers that are specific to API types to api/private/helpers.{c,h}
- Include headers with generated declarations
- Delete unused macros
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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
|
| |
|
|
| |
off_t -> uint64_t
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
this replaces os_get_file_size and file_info.stat.st_size
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This is required by the msgpack-RPC specification. Also, the
send_call/send_event functions were refactored to accept a variable number of
arguments
|
| | |
|
| |
|
|
|
| |
This option makes nvim run in "embedded mode", which creates an API channel via
stdin/stdout and disables all terminal-related code
|
| |
|
|
|
| |
This function can be used to create an API channel that reads/writes from/to
stdin/stdout
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |\
| |
| | |
Implement os_fchown and remove HAVE_FCHOWN
|
| | | |
|
| |/
|
|
| |
Make sure feature pointer is not null before dereferencing.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* With the changes in commit
"events: Refactor how event deferral is handled"
(2e4ea29d2c7b62eb8baf1c41cd43433e085dda0) 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.
|