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/edit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src/nvim/edit.c') diff --git a/src/nvim/edit.c b/src/nvim/edit.c index 5a70964d57..c0a99baf0f 100644 --- a/src/nvim/edit.c +++ b/src/nvim/edit.c @@ -939,7 +939,7 @@ doESCkey: break; case K_EVENT: - event_process(); + event_process(true); break; case K_HOME: /* */ -- cgit