update R startup heuristic

[seeM]

Only start an R runtime immediately if the workspace contains R files, or if it's empty but the user has installed RStudio. This is less likely to incorrectly start R in Python projects for users that happen to have RStudio installed.

See #1282 (comment) for more detail.

[juliasilge]

This won't start R in a workspace that has Quarto or R Markdown files, which is a pretty common situation for R users (no .R files at all, but Quarto or R Markdown files for analysis and reporting).

[seeM]

Good point! Will fix that

[jjallaire]

Rmd files would definitively indicate R. qmd files could of course be either. You can use quarto inspect to determine what "engines" are in play for a project, however I think that would be too slow for this application (~.5 to 1.5 seconds). You could regex scan the qmds looking for R cells as a failsafe?

[seeM]

Here's an updated list of globs from poking around R projects on GitHub:

['*.R', '*.Rmd', '.Rprofile', 'renv.lock', '.Rbuildignore', '*.Rproj']

I'm wondering if the .qmd heuristic is still necessary given the above. How likely is it that an R workspace would not match any of the above, but still have .qmd files with R code blocks?

[jjallaire]

For existing R projects I think *.Rproj would indeed cover any project that had been used in RStudio (which might be good enough). An R project full of .qmd that doesn't have an .Rproj would likely have been created in Positron (increasingly likely as time goes on). So I think for now it would be fine to just key on those extensions but then later I think we may need a bit more introspection (alternatively, for ambiguous cases of .qmd and no other hints we could just use the "default" runtime for a user based on their previous behavior).

[seeM]

I'm going to leave out the qmd heuristic for now, although it's in a725cef (which I've since reverted) if we want it

This is ready for review

[jmcphers]

LGTM.

[jmcphers]

For performance, I think almost all of these should only be searched for at the workspace root since that's the only location at which we expect to find them.

[seeM]

I added **s in all cases to cater for users who open a monorepo at the repo root. My assumption re performance was that, in the worst case, we would still have to iterate through every file in the workspace to check the **/*.R pattern, so it shouldn't be a significant performance drop to add more ** patterns on top of that. Similarly, in the best case, we would match one of the ** patterns early, and the rest wouldn't matter.

[kevinushey]

I've seen a somewhat common pattern where such repositories will have separate sub-directories for different language bindings; e.g. you have a folder for R bindings, Python bindings, and so on. In this scenario, because we cannot really ascertain what the "right" default runtime is, I would argue it would be better to search at the workspace root.

[seeM]

My thinking was that in that case we would start both an R and Python runtime. But if e.g you had multiple sub-directories with R projects using different R versions, I suppose we wouldn't know which specific R version to start, so I agree that we shouldn't set "immediate" startup behavior unless we're very certain. I'll make a follow-up PR.