Feature Request: Shims for {rstudioapi}

[gadenbuie]

Positron Version:

Positron Version: 2023.09.0 (Universal) build 139
Code - OSS Version: 1.79.0
Commit: 7f5dc8c
Date: 2023-09-13T02:39:00.220Z
Electron: 22.3.10
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Darwin arm64 22.6.0

Request

It'd be great to shim rstudioapi so that it works in vscode in a manner similar to how to works in RStudio. The vscode-R extension includes prior art and IIUC the development there was contributed by Miles McBain (a well-known R and vscode user).

Understandable, not everything in rstudioapi can be shimmed, but here's a short list of minimal features:

• Read current selection or editor content
• Insert or replace text in the current editor
• Send a command to the terminal
• Query the current theme foreground/background colors
• Open a file
• Prompt the user for text input
• Prompt the user to locate a local file

[dfalbel]

I would love to be able to run devtools::test_active_file() too, which seems to require rstudioapi::getSourceEditorContext()$path

[DavisVaughan]

We will have to keep in mind that some functions have a version guard through rstudioapi::getVersion(). Not entirely sure what version we should have Positron return https://github.com/search?q=repo%3Arstudio%2Frstudioapi%20getVersion&type=code

[jmcphers]

As per that search, only very old versions of RStudio -- from before the switch to calendar versioning -- are involved. Today getVersion() returns the calendar version.

> rstudioapi::getVersion()
[1] ‘2023.9.0.463’

I think we can just return the Positron version here; because Positron and RStudio both use calendar versioning, returning a calendar version that isn't Positron's version would be very confusing.

Finally, I think most API behavior is gated through hasFun rather than through version checks, and that'll work great with the proposed approach of adding an rstudio namespace that contains functions for the subset of the API that RStudio implements.

[lionel-]

We're making progress on that front! We now have the infrastructure in place to implement rstudioapi shims and one POC method that lets usethis::use_r() and usethis::use_test() switch between source and test files inside Positron.

[DavisVaughan]

Requests for codegrip::addin_reshape() support:

• rstudioapi::getActiveDocumentContext() needs to return the selection info (it just returns the file now)
• rstudioapi::modifyRange()
• rstudioapi::setCursorPosition()

[jennybc]

I'm also really interested in getting selection info/content re: making more reprex more featureful in Positron. Therefore, my current plan for "Jenny's first rstudioapi shim work" is to attempt that.

[jennybc]

Another high priority is finding a way to emulate/intercept rstudioapi::executeCommand("activateConsole"). The lack of that appears to be why devtools::test_active_file() doesn't work yet. And, even in some things that are (mostly) working, such as usethis::use_r()/use_test(), I feel like there's some unexpected behaviour around where focus ends up.

[jmcphers]

Last week I added workbench.action.positronConsole.focusConsole which should be a drop-in replacement for RStudio's activateConsole when we're ready to hook it up.

[jennybc]

With the merge of #2132, rstudioapi::getActiveDocumentContext() now works, which is the first bullet in the wish list above:

• Read current selection or editor content

> x <- rstudioapi::getActiveDocumentContext()
> x
Document Context: 
- id:        ''
- path:      'Untitled-2'
- contents:  <5 rows>
Document Selection:
- [1, 1] -- [1, 3]: '🤖🌷'
- [2, 1] -- [2, 3]: 'Ab'
- [3, 1] -- [3, 3]: '!😱'
- [4, 1] -- [4, 3]: '?💅'
> x$contents
[1] "🤖🌷" "Ab"   "!😱"  "?💅"  ""    
> x$selection[[1]]$text
[1] "🤖🌷"

[jennybc]

It's somewhat overoptimistic to say that we support both getActiveDocumentContext() and getSourceEditorContext() fully because right now they are the same thing. I explain the deal in posit-dev/ark#237. That being said, I don't think it's a high priority to decouple them.

[jennybc]

I note that devtools::test() in the Console (our current default, although not forever #2378) now leads to these messages:

Coming from:

https://github.com/r-lib/testthat/blob/f060ccec365e1343ae926c53c215a423b295d7a8/R/utils.R#L61-L62

That suggests that these specific RStudio commands are a high priority.

[juliasilge]

In posit-dev/ark#267 I included support for the 'refreshFiles' and 'vcsRefresh' commands. ✅

[juliasilge]

I tend to think we are OK for Public Beta on supporting RStudio commands, and should wait on reports/feedback to add more:
https://github.com/search?q=rstudioapi::executeCommand&type=code

You can see what we have here:
https://github.com/posit-dev/amalthea/blob/main/crates/ark/src/modules/rstudio/commands.R

[jennybc]

Lately I've also been wishing that rstudioapi::openProject() worked. usethis uses it in some key workflows. And this sort of programmatic method of project launch also feels like a nice addition, in terms of giving more options there (given that, e.g., Alfred workflows don't immediately work for Positron today).

https://github.com/rstudio/rstudioapi/blob/1dc8723eac5fc6373b80abe00342a1de60964ca3/R/stubs.R#L516-L518

[juliasilge]

I got rstudioapi::openProject() working in #2501 -- it will be in tomorrow's build 🙌

[juliasilge]

There is a lot of work here and there are pretty detailed notes of what to try in the various PRs, but here would be a smorgasbord of testing:

"hello 🌍, I like crème brûlée!"
"hello 🌷, I like crème brûlée!"
"hello 🤖, I like crème brûlée!"
"hello 🤷‍♀️, I like crème brûlée!"
"hello 😭, I like crème brûlée!"
"hello 💩, I like crème brûlée!"
"hello 🤷‍♀️, I like crème brûlée!"
"hello 🥔, I like crème brûlée!"

rstudioapi::setCursorPosition(rstudioapi::document_position(5, 1))

rgs <- list(
    rstudioapi::document_range(rstudioapi::document_position(2, 3), rstudioapi::document_position(3, 1)),
    rstudioapi::document_range(rstudioapi::document_position(4, 7), rstudioapi::document_position(4, 20)),
    rstudioapi::document_range(rstudioapi::document_position(5, 7), rstudioapi::document_position(5, 20)),
    rstudioapi::document_range(rstudioapi::document_position(6, 7), rstudioapi::document_position(6, 20)),
    rstudioapi::document_range(rstudioapi::document_position(10, 1), rstudioapi::document_position(10, 2))
)
rstudioapi::setSelectionRanges(rgs)

rstudioapi::insertText(lapply(1:5, function(x) c(x, 8, x, 9)), "🤷")
rstudioapi::modifyRange(Map(c, 1:5, 1), paste0("#", sample(letters, 5), " "))

rstudioapi::showQuestion("Howdy there!", "I think you're great!!!", "😊", "😫")
rstudioapi::showDialog("Howdy there!", "It's time to visit a <i>very nice</i> website:", "https://posit.co/")

rstudioapi::sendToConsole("lm(mpg ~ ., data = mtcars)")
rstudioapi::restartSession()
rstudioapi::getActiveProject()
rstudioapi::documentNew("SELECT * FROM 1", type = "sql")
rstudioapi::openProject("/path/to/a/new/workspace/", TRUE)
rstudioapi::navigateToFile("/path/to/a/file.R") ## also works with relative paths
rstudioapi::executeCommand("activateTerminal")

# generates an info box for user:
rstudioapi::executeCommand("potato")

Create an R file with this code ⤴️ and then step through via Cmd+Enter, starting with line 10.

[juliasilge]

If we come up with any new work needed for rstudioapi shims, let's open new issues. 👍

[jennybc]

Are we going to link #2605 to this? Or do we view that as one of these new issues?

[juliasilge]

Yes, we'll triage #2605 and decide whether to handle it for Public Beta. Thank you for the detailed info on the remaining problem!

[jonvanausdeln]

@juliasilge , will these be available from Python? I'm assuming this is an R package, and we'd need something separate for Python?

[juliasilge]

These could eventually be made available to users in Python in the future, say if we decided to create a Python package positronapi or similar, but as of today they are available to R users only. The functionality is available in the Python extension (see here for example) but we don't need to validate that as of today.

[jonvanausdeln]

Verified Fixed

Positron Version(s) : 2024.04.0-29
OS Version(s) : Windows 11

Test scenario(s)

All the mentioned api calls work as expected. I didn't check all the possible for executeCommand.

Link(s) to TestRail test cases run or created:

Test 607955 - Not exhaustive, but will be expanded when automated.