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

diff --git a/src/nvim/message.c b/src/nvim/message.c
index 281270155a..1571e8678f 100644
--- a/src/nvim/message.c
+++ b/src/nvim/message.c
@@ -2064,7 +2064,7 @@ static int do_more_prompt(int typed_char)
     toscroll = 0;
     switch (c) {
     case K_EVENT:
-      event_process();
+      event_process(true);
       break;
     case BS:                    /* scroll one line back */
     case K_BS: