Unreliable readline prompt detection with active browser sessions

[lionel-]

When R requests inputs, we don't know for sure what is the intent:

• The next top-level command to execute
• The next command to execute in a debugging session
• The last command was incomplete and R requests more input to complete it
• Some running R code requests input via readline() or menu()

We currently use heuristics to determine these cases (see prompt_info).

Since posit-dev/ark#346, we have made the detection of debug prompts more reliable at the expense of the detection of readline prompts. Here is a reprex:

foo <- function() {
  bar()
  NULL
}

bar <- function() {
  readline("foo ")
}

debug(foo)
foo()

Once in foo(), step over bar(). Ark drops in the debugger again, inside readline().

Possible fixes:

• Eventually we would like to contribute an extended ReadConsoleExt() hook to R where contextual information would be passed via a struct. Then we would know for sure what kind of prompts we're dealing with.

• In the meantime we could detect readline() or menu() on the stack and never drop in the debugger in that case, and instead treat the prompt like a readline request. However that would get us in a weird state with debug(readline) (or a user stepping in it by accident with F11).

• We could match Browse[%d]> in the prompt string. If it matches, it's a browser prompt, otherwise, it's a readline prompt running within a debug session. We could still be tricked by readline("Browse[0]> ") but I think that's ok.

[DavisVaughan]

This particular example looks nice to me now. Compared to above, we temporarily exit the debug state to allow the user to type in their input-reply, and then we drop back in to the debugger on the next line.

Screen.Recording.2024-10-04.at.12.46.39.PM.mov