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/normal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src/nvim/normal.c') diff --git a/src/nvim/normal.c b/src/nvim/normal.c index f4f03f4ff8..9fb096f7d2 100644 --- a/src/nvim/normal.c +++ b/src/nvim/normal.c @@ -7368,5 +7368,5 @@ static void nv_cursorhold(cmdarg_T *cap) static void nv_event(cmdarg_T *cap) { - event_process(); + event_process(true); } -- cgit