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.
To make it possible reuse `event_poll` recursively and in other blocking
function calls, this changes how deferred/immediate events are processed:
- There are two queues in event.c, one for immediate events and another for
deferred events. The queue used when pushing/processing events is determined
with boolean arguments passed to `event_push`/`event_process` respectively.
- Events pushed to the immediate queue are processed inside `event_poll` but
after the `uv_run` call. This is required because libuv event loop does not
support recursion, and processing events may result in other `event_poll`
calls.
- Events pushed to the deferred queue are processed later by calling
`event_process(true)`. This is required to "trick" vim into treating all
asynchronous events as special keypresses, which is the least obtrusive
way of introducing asynchronicity into the editor.
- RStream instances will now forward the `defer` flag to the `event_push` call.
These functions will never be called directly by the user so bugs are the only
reason for passing invalid channel ids. Instead of returning silently we abort
to improve bug detection.
- Removed 'copy' parameter from `wstream_new_buffer`. Callers simply pass a
copy of the buffer if required.
- Added a callback parameter, which is used to notify callers when the data is
successfully written. The callback is also used to free the buffer(if
required) and is compatible with `free` from the standard library.
Before this change, any write that could cause a WStream instance to use more
than `maxmem` would fail, which is not acceptable when writing big chunks of
data. (This could happen when returning contents from a big buffer through the
API, for example).
Writes of any size are now allowed, but before we check if the currently used
memory doesn't break the limit. This should be enough to prevent us from
stacking data when talking to a locked process.
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.
