When these events occurs the relevant handlers are called, and so begins
the chain of messages that results in anything happening in the editor.
-FIXME this isn't quite right at present.
-The event subsystems isn't quite the ultimate starting point. The
-editor must have a main loop with sends the message "event:run" to the
-root pane, and then runs "pane_refresh()" on that pane. The "event:run"
-handler, registered by the event subsystem, determines what events have
-happening, if any, and calls the relevant handlers.
+The event subsystem handles all events. After any initialisation it is
+sufficient to call it repeatedly with the "event:run" message while it
+returns 1.
The messages that the event subsystem listens for are:
### Medium
-- [ ] add event:on-idle with 3 priority levels
+- [X] add event:on-idle with 3 priority levels
- [X] Always do word-count async.
- [X] lib-url
- [ ] lib-mergeview improvements
- [ ] give every pane a link to root/editor main and use that
instead of statics. Then maybe times_up() can use pane_too_long()
- [ ] mark DEF_CMD structs as const
-- [ ] add event:on-idle with 3 priority levels
+- [X] add event:on-idle with 3 priority levels
2 - fast cleanup that must be run immediately
1 - slower general response to recent command: typically
pane_refresh
if (first_window) {
call("global-multicall-startup-", first_window);
- while (call("event:run", ed) == 1) {
- time_start(TIME_IDLE);
- call("global-multicall-on_idle-", ed);
- time_stop(TIME_IDLE);
- }
+ while (call("event:run", ed) == 1)
+ ;
} else
fprintf(stderr, "edlib: cannot create a display\n");
pane_close(ed);