From 0621a6eaa51c8fc7a925b2578f8775b8ddd3d837 Mon Sep 17 00:00:00 2001 From: Thiago de Arruda Date: Tue, 17 Jun 2014 12:27:08 -0300 Subject: 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. --- src/nvim/message.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src/nvim/message.c') 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: -- cgit