Looks like a step in the right direction!

The main thing I'd like us to be careful about is to not break native infrastructure that could potentially be used outside Positron:

• Native graphics devices: GraphApp-based on Windows, Cocoa/Quartz on macOS, X11 on Linux.
• Less important but comes up in practice: tcl/tk GUIs. R prompts user for a CRAN repo with a tcl/tk menu.

For some reason the tcltk package refuses to even load on my machine (R freezes) so I couldn't verify that it still works. But I could verify the Quartz graphics device no longer works, even though it does work on main. That's because Ark now sets ptr_R_ProcessEvents, see inline comment.

I did a deep dive in R's messy ecosystem of events loop (see below). I think we could simplify things and keep everything working with the following setup:

Windows:

pub fn pump_idle_events() {
    // R_ProcessEvents on Windows contains peekevent/doevent (GraphApp pump),
    // time limits, UserBreak, ptr_ProcessEvents (our hook), and R_Tcl_do.
    // No R_runHandlers / input-handler concept on Windows.
    unsafe { R_ProcessEvents() };
}

pub fn setup_r(args: &Vec<String>) {
    (*params).CallBack = Some(r_flush_debug_filter);
}

Unix:

pub fn pump_idle_events() {
    // ptr_R_ProcessEvents (Quartz), R_PolledEvents (debug_filter + tcltk),
    // R_CheckTimeLimits.
    unsafe { R_ProcessEvents() };

    // Drain ready input handlers (Quartz pipe, X11, later, help server).
    let mut fdset = unsafe { R_checkActivity(0, 1) };
    while !fdset.is_null() {
        unsafe { R_runHandlers(libr::get(R_InputHandlers), fdset) };
        fdset = unsafe { R_checkActivity(0, 1) };
    }

    // Match R's sys-std.c:1136 idiom: one final call with NULL fires
    // Rg_PolledEvents (Cairo X11 buffered display flush) and R_PolledEvents
    // (re-fires debug_filter + tcltk; both idempotent).
    unsafe { R_runHandlers(libr::get(R_InputHandlers), std::ptr::null_mut()) };
}

pub fn setup_r(args: &Vec<String>) {
    libr::set(R_PolledEvents, Some(r_flush_debug_filter));
    libr::set(R_wait_usec, 10000);
    // ptr_R_ProcessEvents intentionally not set as it's reserved for Quartz.
}

The other thing I'm wondering for a follow-up PR is if we should wait on the activity hanlder fds directly, on Unix. R_InputHandlers is a public linked list so it should be possible, I think Kevin had a comment about this (might have been deleted since): https://github.com/r-devel/r-svn/blob/714af4bf22bebd387437e31c397167996b4d5fbc/src/include/R_ext/eventloop.h#L93

The advantage would be that we'd run {later} callbacks and R's help server requests as soon as the events come in, without any timeout delays.

Notes from deep dive:

Interrupt-time: R_CheckUserInterrupt() calls R_ProcessEvents()

Unix R_ProcessEvents()

• Ptr_R_ProcessEvents()
• R_PolledEvents()
• R_CheckTimeLimits()

Windows R_ProcessEvents()

• GraphApp events
• R_CheckTimeLimits()
• Interrupt check
• Ptr_R_ProcessEvents()
• R_Tcl_do()

R_runHandlers (Unix only)

• Run activity/input handlers registered by packages (e.g. grDevices on mac, later on linux and mac)
• Runs only when R is idle, never when busy. Called by ReadConsole's Unix implementation.

Ptr_R_ProcessEvents

• macOS: Set by Cocoa, only if pointer still NULL. We can't set this without breaking Cocoa GUI.
• Windows: Mapped to Rp->Callback

R_PolledEvents (Unix only): Called from ProcessEvents()
-> Global pointer, only set by tcl/tk in stack-like fashion (calls old pointer)

Rg_PolledEvents: Separate hook for X11, called alongside R_PolledEvents when R_runHandlers is passed a NULL readMask (when R_checkActivity() returns NULL).

tcl/tk (Unix):

• Interrupt-time: Sets R_PolledEvents on Unix (in a stack-like pattern, calling the old handler if any is set), R_Tcl_do on Windows
• Idle: Does not register an activity input handler
• Bidirectional: Sets a TCL event loop handler to call R_runHandlers when TCL is itself busy (e.g. running a modal dialog).

X11 (Unix): Runs on the R thread

• Interrupt-time: nothing. X11 does not register Ptr_R_ProcessEvents, so X11
  windows freeze during R computation. (Cairo-buffered X11 devices additionally
  set Rg_PolledEvents = CairoHandler for periodic buffer flushes, but
  Rg_PolledEvents only fires from the legacy R_runHandlers(handlers, NULL)
  branch, which ark never invokes.)
• Idle: Registers an activity input handler on the X11 connection fd
  (addInputHandler(R_InputHandlers, ConnectionNumber(display), R_ProcessX11Events, XActivity)). The X
  server pushes events to the connection fd, select() sees the fd ready,
  R_runHandlers dispatches to R_ProcessX11Events.

Quartz/Cocoa: Runs on the R thread

• Interrupt-time: Registers Ptr_R_ProcessEvents if NULL
• Idle-time: Registers an activity input handler for idle time events. Tickled by a background thread that sets a byte on the write end every 100ms.
• If Ptr_R_ProcessEvents is NULL, also initialises Cocoa GUI in the current process, which sets it as a full-blown foreground process visible in the Dock.

HTML help server (Unix): Server runs on the R thread

• Interrupt-time: Nothing, Help server is unresponsive when R is busy
• Idle-time: Registers an activity input handler on the listening TCP socket
  (srv_input_handler).
  When a connection arrives, that handler calls
  accept() and registers another input handler on the per-connection
  socket (worker_input_handler) to serve the request. So each in-flight
  request has its own input handler.

HTML help server (Windows): Server runs in a separate thread.

later (Unix):

• Interrupt-time: Nothing
• Idle-time: Registers an activity input handler (that checks call stack is empty in case of debugger read-prompt)

later (Windows):

• Spawns a message-only window that checks every 10ms