events: Refactor how events are queued for processing

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.

1 files changed, 5 insertions, 12 deletions

diff --git a/src/nvim/os/rstream.c b/src/nvim/os/rstream.c
index bbff12dd42..81714f7bae 100644
--- a/src/nvim/os/rstream.c
+++ b/src/nvim/os/rstream.c
@@ -340,16 +340,9 @@ static void close_cb(uv_handle_t *handle)
 
 static void emit_read_event(RStream *rstream, bool eof)
 {
-  if (rstream->defer) {
-    Event event;
-
-    event.type = kEventRStreamData;
-    event.data.rstream.ptr = rstream;
-    event.data.rstream.eof = eof;
-    event_push(event);
-  } else {
-    // Invoke the callback passing in the number of bytes available and data
-    // associated with the stream
-    rstream->cb(rstream, rstream->data, eof);
-  }
+  Event event;
+  event.type = kEventRStreamData;
+  event.data.rstream.ptr = rstream;
+  event.data.rstream.eof = eof;
+  event_push(event, rstream->defer);
 }