- New API function to push data to the typeahead buffer - this should
equivalent to the vimscript feedkeys() function
- In Vim there was a --remote-send command to insert input into a
Vim server instance. Besides accepting key sequences it also
translated special keys such as <CR> or <Leader>, backslash notation
is ignored. This commit backports the original Vim handler for
--remote-send as a bool option for vim_feedkeys()
- vim-patch:0
This simplifies the generated msgpack_rpc_dispatch() function, separates the
code for each RPC method more clearly and allows easy implementation of
alternative dispatching methods (e.g. string method id dispatch).
This macro is used to append an element to a growable array. It replaces this
common idiom:
ga_grow(&ga, 1);
((item_type *)ga.ga_data)[ga.ga_len] = item;
++ga.ga_len;
I know it could be 0 sometimes. Running the tests with
`assert(gap->ga_growsize > 0)` in ga_grow() crashes nvim while running the
tests.
- Add a setter for ga_growsize that checks whether the value passed is >=1 (log
in case it's not)
- log when ga_grow() tries to use a ga_growsize that's not >=1
- use GA_EMPTY_INIT_VALUE is many places
The old mch_libcall was removed from neovim. This is a partial
reimplementation on top of libuv. It doesn't catch exceptions (windows) nor
signals (unix) though, so it's quite a bit more prone to crashing if the
loadable library throws an exception or crashes. Still, it should be fine
for well-behaved libraries. Requested by @Shougo.
* FileID can’t be used in memline.c, because the block0 is defined to
use only a 32bit ino.
* implemented `os_file_info_get_inode`
* deprecated `os_file_info_get_inode
`FileID` should encapsulate `st_dev` and `st_ino`. It is a new abstraction
used to check if two files are the same. `FileID`s will be embeded inside
other struts like `buf_t` or `ff_visited_T`, where a full `FileInfo` would be
to big.
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
This function is used to send RPC calls to clients. In contrast to
`channel_send_event`, this function will block until the client sends a
response(But it will continue processing requests from that client).
The RPC call stack has a maximum depth of 20.
- 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
This was done to generalize the usage of `event_poll`, which will now return
`true` only if a event has been processed/deferred before the timeout(if not
-1).
To do that, the `input_ready` calls have been extracted to the input.c
module(the `event_poll` call has been surrounded by `input_ready` calls,
resulting in the same behavior).
The `input_start`/`input_stop` calls still present in `event_poll` are
temporary: When the API becomes the only way to read user input, it will no
longer be necessary to start/stop the input stream.
In win_close_othertab: Code can never be reached because of a
logical contradiction (CWE-561).
Pointer tp cannot be NULL at this point, so conditional operator ? can
be replaced with its second expression.
