Add r.rterm.preferredConsoles for R console selection from PATH by BerriJ · Pull Request #1625 · REditorSupport/vscode-R

BerriJ · 2025-07-11T15:06:56Z

This PR will close #1347

It adds a new option r.rterm.preferredConsoles which defaults to ["R"]. You can specify you preferred R consoles like this:

The extension will open the first item in that list that it finds on the users PATH. However, if r.rterm.linux is specified, it will use that path (given that this is a more precise setting, I suggest we give precedence to it).

Thank you so much for this project. I'm a daily user since many years.

Best,
BerriJ

eitsupi · 2026-01-31T14:56:47Z

Would it make more sense to make R and radian selectable via an Enum?

I recently created the arf console that can be used instead of radian, and I have personally switched from radian.
https://github.com/eitsupi/arf

BerriJ · 2026-02-03T13:22:52Z

Would it make more sense to make R and radian selectable via an Enum?

I recently created the arf console that can be used instead of radian, and I have personally switched from radian. https://github.com/eitsupi/arf

This would also work. You mean something like:

preference = [arf, radian, r]

And then this extension would search the PATH for arf, radian, and r, and use the first it finds?

This would be a very flexible solution.

grantmcdermott · 2026-02-03T20:30:02Z

+1 on arf support. I've been using it for the last few days and it's solved several long-standing radian headaches for me.

grantmcdermott · 2026-04-15T22:23:42Z

Fwiw, radian is no longer being (actively) maintained. The package readme explicitly recommends switching over to arf:

radian is no longer under active development. While I may address critical or obvious bugs, no new features will be added. If you are looking for an active alternative, I recommend checking out arf by @eitsupi.

BerriJ · 2026-04-16T11:21:35Z

@randy3k Do you have an idea how to proceed here? I could happily adjust the PR to use arf instead of radian, now that radian is not supported anymore.
I'm also happy to implement other ideas. The core feature I'd need is that vscode-R picks the specified R executable from the PATH, and we do not have to hardcode the specific path in the settings. As discussed here: #1347

I'm also not shure if this PR is completely independent from #1684. Maybe you could tell us something about the big picture here. Many thanks in advance :)

randy3k · 2026-06-26T22:21:51Z

We shouldn't reply on radian anymore (python is not really a good platform for development an R console).

I am not oppposing to the idea of "prefer arf". Though I am not sure if we want to "hard code" arf at the same time. A setting like "prefer this program if found" may be more useful?

BerriJ · 2026-07-20T13:14:39Z

We shouldn't reply on radian anymore (python is not really a good platform for development an R console).

I am not oppposing to the idea of "prefer arf". Though I am not sure if we want to "hard code" arf at the same time. A setting like "prefer this program if found" may be more useful?

Thanks for your feedback. I agree, hardcoding R consoles is not ideal. I updated the PR and now the new setting takes a list of console names that the user prefers. So you can specify for example ["arf", "radian", "R"] and it will use arf, if available on the PATH, otherwise it falls back to "radian" and so on. Would you mind taking a look at this?

I'll gladly adjust this further, based on your feebdack.

BerriJ · 2026-09-17T13:28:12Z

@randy3k would you mind taking a look at this PR again? IMHO it's ready.

grantmcdermott

I test locally it and seems to be working well.

I think it's probably out of scope. But my one question (concern?) is whether the "r.bracketedPaste" shouldn't be coupled with this new entry, since users will get garbled output for arf and radian if this field isn't set to true. Maybe a future "r.bracketedPaste": "auto" configuration could enable this automatically in an intelligent way?

eitsupi · 2026-09-18T00:28:05Z

I think this PR has been waiting for a long time, so I would not object to merging it as-is.

However, since it adds yet another configuration option to an extension that already has quite a few of them, I think we should also consider cleaning up the overall configuration design.

I asked ChatGPT to look at this from that longer-term perspective, and the main points were:

r.rpath.* and r.rterm.* currently resolve R independently, which is one reason users sometimes have to configure the same R installation in multiple places.
Instead of adding r.rterm.preferredConsoles, we could eventually allow existing r.rterm.* settings to accept either an absolute path or an executable name such as arf, resolving the latter from PATH.
If r.rterm.* is not explicitly configured, it could fall back to the R resolved by r.rpath.*.
Executable resolution could be centralized into a shared resolver rather than being implemented separately for R and interactive consoles.
Longer term, the OS-specific settings (r.rpath.windows/mac/linux and r.rterm.windows/mac/linux) could potentially be reduced to something like r.rpath and r.rterm, with the old settings kept temporarily for compatibility.

So I am fine with merging this PR for now, but if @grantmcdermott and others agree with the general direction, I would like to revisit this (in v4?) and reduce the number of configuration options rather than continuing to add more.

From my perspective, there may also eventually be a case for treating arf specially.
It already provides much of the functionality needed for integration with an R session, and it can resolve the underlying R installation itself.
In principle, I think even bundling arf with vscode-R could be technically feasible.
But that is probably a separate discussion from this PR.

grantmcdermott · 2026-09-18T00:38:53Z

Those all sound like good ideas to me 👍

BerriJ · 2026-09-18T18:17:48Z

Sound great! Thank you all :)
This would be awesome. My entire team will be able to remove a nasty workaround if r can be grabbed from the PATH.
I can also contribute to a new PR which consolidates the settings like @eitsupi suggested.

grantmcdermott · 2026-09-18T18:56:05Z

I've found copilot review comments to be quite helpful lately. So I'll ask it to do one last pass before we merge.

Copilot

🟡 Changes recommended

Fix missing-setting handling and skip blank console entries during PATH lookup.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds configurable PATH-based selection for the R console while preserving explicit terminal paths and system fallback.

Changes:

Adds r.rterm.preferredConsoles, defaulting to ["R"].
Searches configured console names in preference order.
Declares the new setting in the extension configuration.

File summaries

File	Summary
`src/util.ts`	Implements preferred console PATH resolution.
`package.json`	Declares the new configuration option.

Review details

Suppressed comments (2)

src/util.ts:140

getRterm() is called by the existing session integration tests with a configuration stub whose get method returns undefined for unknown keys and ignores the default argument. In that case this value is undefined, so the for...of below throws before the existing R-path fallback runs. Normalize the result with ?? ['R'] (or otherwise guard the array) so missing/invalid settings retain the documented default.

        const preferredConsoles = config().get<string[]>('rterm.preferredConsoles', ['R']);

src/util.ts:146

This introduces ordered PATH selection and explicit-path precedence, but the existing terminal/session tests do not exercise this branch. A focused test should stub the PATH and configuration to verify that an explicit rterm.<platform> wins, otherwise the first existing preferred console wins, and the fallback remains the system R path; these cases are otherwise easy to regress without the suite detecting it.

        const preferredConsoles = config().get<string[]>('rterm.preferredConsoles', ['R']);

        for (const consoleName of preferredConsoles) {
            rpath = getRfromEnvPath(platform, consoleName);
            if (rpath) {
                break;
            }

Files reviewed: 2/2 changed files
Comments generated: 1
Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

grantmcdermott · 2026-09-18T20:04:07Z

+        const platform: string = process.platform;
+        const preferredConsoles = config().get<string[]>('rterm.preferredConsoles', ['R']);
+
+for (const consoleName of preferredConsoles) {


@BerriJ Looks like you just need to indent this properly.

Done, and while I was at it, I also squashed the commits together.

grantmcdermott · 2026-09-18T20:21:00Z

Remaining CI failure is a pre-existing issue (which we should probably address soon-ish).

Thanks @BerriJ!

eitsupi · 2026-09-19T09:23:51Z

I've opened #1735

Close #597 Close #1437 Supersede #1625 Related to #1130 ## Summary - add `r.executablePath` as the canonical vanilla R executable for language-server and other background processes - add `r.consolePath` as the canonical interactive console executable, including bare executable names resolved from `PATH` (for example, `arf` or `radian`) - formally deprecate the six platform-specific `r.rpath.<platform>` and `r.rterm.<platform>` settings while preserving them as compatibility inputs - Show a one-time compatibility warning when an installed R Debugger version still registers the legacy `r.rpath.<platform>` settings - remove the unreleased `r.rterm.preferredConsoles` setting and the previously deprecated, unused `r.helpPanel.rpath` setting - add host-independent regression coverage for precedence, PATH and registry discovery, substitutions, quoting, and workspace edge cases - resolve executable settings and `${workspaceFolder}` against the relevant workspace or document resource when one is available ## Why these names? The names follow the convention used by other VS Code language extensions: for example, Python uses `python.defaultInterpreterPath`, Julia uses `julia.executablePath`, and Ruby LSP uses `rubyLsp.rubyExecutablePath`. `executablePath` clearly identifies the vanilla executable used by the extension, while the parallel `consolePath` name preserves vscode-R's important distinction between background R and an alternative interactive console. We cannot use the shorter `r.rpath` and `r.rterm` while retaining their legacy platform-specific children: VS Code treats dotted configuration identifiers hierarchically, so scalar parent settings conflict with `r.rpath.windows`, `r.rterm.linux`, and the other existing keys. The `Path` suffix also makes clear that these settings select an executable location (including a name resolved from `PATH`), rather than configuring console behavior more broadly. ## Resolution rules Background/vanilla R resolves in this order: 1. `r.executablePath` 2. legacy `r.rpath.<current platform>` 3. `R` on `PATH` 4. Windows registry `InstallPath` (Windows only) The interactive console resolves in this order: 1. `r.consolePath` 2. legacy `r.rterm.<current platform>` 3. an explicitly configured `r.executablePath` 4. system R (`PATH`, then the Windows registry) The distinction between background R and the interactive console remains intentional: background processes never use `r.consolePath` or legacy `r.rterm.<platform>`. Also, a legacy `r.rpath.<platform>` override does not begin controlling the console; only the new canonical `r.executablePath` can provide that default. Both canonical settings use `machine-overridable` scope because executable locations are machine-dependent while workspace overrides remain useful. Relevant terminal, language-server, task, R Markdown, C++ properties, and command call sites now pass their workspace or document URI so folder-level settings and `${workspaceFolder}` substitution use the same resource. Empty values are treated as unset. Explicit but unavailable values fail instead of silently selecting a different executable. ## Historical compatibility The old settings were split by OS when defaults were hard-coded installation paths. The resolver keeps the later discovery behavior added for real-world installations: - `R` on `PATH` takes priority over the Windows registry (#244, #252, #649) - background commands use vanilla R, independently of alternative consoles (#607, #695 and commit `5e9c895`) - `${userHome}`, `${workspaceFolder}`, `${fileWorkspaceFolder}`, and `${fileDirname}` substitutions remain supported (#1398, #1444) - quoted paths and paths containing spaces remain supported (#884) - a bare name is looked up on `PATH`, never interpreted as a workspace-relative path (#1347, #1437) The platform-specific settings remain supported for backward compatibility but are deprecated in favor of the canonical settings and may be removed in a future release. ## Scope boundaries and deliberate follow-ups - `.github/ISSUE_TEMPLATE/bug_report.md` intentionally remains unchanged even though it contains legacy setting examples. The template needs a broader rewrite, which will be handled separately rather than partially updating it in this PR. - This PR makes executable configuration lookup resource-aware, but does not introduce a complete per-folder runtime lifecycle. In particular, it does not restart the help subsystem when the active folder changes or redesign single-/multi-server LSP lifecycle behavior.

BerriJ mentioned this pull request Oct 17, 2025

WIP R Executable Selection #1473

Draft

BerriJ force-pushed the master branch 2 times, most recently from 6137443 to 70b621a Compare July 20, 2026 13:02

BerriJ changed the title ~~Default to radian console if rterm.preferRadian is true~~ Add r.rterm.preferredConsoles for R console selection from PATH Jul 21, 2026

grantmcdermott assigned grantmcdermott and unassigned grantmcdermott Sep 17, 2026

grantmcdermott self-requested a review September 17, 2026 19:24

grantmcdermott approved these changes Sep 17, 2026

View reviewed changes

grantmcdermott requested a lite review from Copilot September 18, 2026 18:56

Copilot started reviewing on behalf of grantmcdermott September 18, 2026 18:56 View session

Copilot AI reviewed Sep 18, 2026

View reviewed changes

Comment thread src/util.ts

grantmcdermott reviewed Sep 18, 2026

View reviewed changes

feat: add r.rterm.preferredConsoles for flexible R console selection

79fb16c

BerriJ force-pushed the master branch from 22d2471 to 79fb16c Compare September 18, 2026 20:08

grantmcdermott merged commit cb163d2 into REditorSupport:master Sep 18, 2026
4 of 5 checks passed

eitsupi mentioned this pull request Sep 19, 2026

feat!: simplify R executable / console path settings #1735

Merged

Conversation

BerriJ commented Jul 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eitsupi commented Jan 31, 2026

Uh oh!

BerriJ commented Feb 3, 2026

Uh oh!

grantmcdermott commented Feb 3, 2026

Uh oh!

grantmcdermott commented Apr 15, 2026

Uh oh!

BerriJ commented Apr 16, 2026

Uh oh!

randy3k commented Jun 26, 2026

Uh oh!

BerriJ commented Jul 20, 2026

Uh oh!

BerriJ commented Sep 17, 2026

Uh oh!

grantmcdermott left a comment

Choose a reason for hiding this comment

Uh oh!

eitsupi commented Sep 18, 2026

Uh oh!

grantmcdermott commented Sep 18, 2026

Uh oh!

BerriJ commented Sep 18, 2026

Uh oh!

grantmcdermott commented Sep 18, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Suppressed comments (2)

Uh oh!

Uh oh!

grantmcdermott Sep 18, 2026

Choose a reason for hiding this comment

Uh oh!

BerriJ Sep 18, 2026

Choose a reason for hiding this comment

Uh oh!

grantmcdermott commented Sep 18, 2026

Uh oh!

Uh oh!

eitsupi commented Sep 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

BerriJ commented Jul 11, 2025 •

edited

Loading