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, 3 insertions, 3 deletions

diff --git a/src/nvim/ex_getln.c b/src/nvim/ex_getln.c
index 02c82eaf21..9b09abb1b7 100644
--- a/src/nvim/ex_getln.c
+++ b/src/nvim/ex_getln.c
@@ -758,7 +758,7 @@ getcmdline (
      */
     switch (c) {
     case K_EVENT:
-      event_process();
+      event_process(true);
       // Force a redraw even though the command line didn't change
       shell_resized();
       goto cmdline_not_changed;
@@ -1873,8 +1873,8 @@ redraw:
       }
 
       if (IS_SPECIAL(c1)) {
-        // Process pending events
-        event_process();
+        // Process deferred events
+        event_process(true);
         // Ignore other special key codes
         continue;
       }