| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is how asynchronous events are currently handled by Nvim:
- Libuv event loop is entered when Nvim blocks for user input(os_inchar is
called)
- Any event delivered by libuv that is not user input is queued for processing
- The `K_EVENT` special key code is returned by os_inchar
- `K_EVENT` is returned to a loop that is reading keys for the current Nvim
mode, which will be handled by calling event_process()
This approach has the advantage of integrating nicely with the current
codebase, eg: vimscript code can be executed asynchronously with little
surprises(Its the same as if the user typed a key).
The problem with using keys to represent any event is that it also interferes with
operators, and not every event needs or should do that. For example, consider
this scenario:
- A msgpack-rpc client calls vim_feedkeys("d")
- Nvim processes K_EVENT, pushing "d" to the input queue
- Nvim processes "d", entering operator-pending mode to wait for a motion
- The client calls vim_feedkeys("w"), expecting Nvim to delete a word
- Nvim processes K_EVENT, breaking out of operator-pending and pushing "w"
- Nvim processes "w", moving a word
This commit fixes the above problem by removing all automatic calls to
`event_push`(which is what generates K_EVENT input). Right now this also breaks
redrawing initiated by asynchronous events(and possibly other stuff too, Nvim is
a complex state machine and we can't simply run vimscript code anywhere).
In future commits the calls to `event_push` will be inserted only where it's
absolutely necessary to run code in "key reading loops", such as when executing
vimscript code or mutating editor data structures in ways that currently can
only be done by the user.
|
| |
|
|
|
|
| |
This approach is more flexible because we don't need to support a fixed set of
"event types", any module can push events to be handled in main loop by simply
passing a callback to the Event structure.
|
| |
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
rbuffer_data was renamed to rbuffer_read_ptr, and it represents the next read
position in a RBuffer instance. Similarly, rbuffer_write_ptr was added to
represent the next write position.
Also, rbuffer_data was being used for writing(in alloc_cb), replace that by
rbuffer_write_ptr.
|
| |
|
|
|
| |
This field is used in a conditional jump, so this initialization is fixing a
bug.
|
| |
|
|
|
| |
All input buffer code was moved to os/input.c, and `inbuf` is now a `RBuffer`
instance(which abstracts static buffer manipulation).
|
| |
|
|
|
|
|
|
| |
RBuffer instances represent the internal buffer used by RStreams.
This changes RStream constructor to receive RBuffer pointers and adds a set of
RBuffer methods that expose the lower level buffer manipulation to consumers of
the RStream API.
|
| |
|
|
|
|
|
|
| |
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
|
