You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Combine rterm/rpath settings for different operating systems? #597
We have separate settings for R paths on different platforms:
r.rpath.windows, r.rpath.mac, r.rpath.linux
r.rterm.windows, r.rterm.mac, r.term.linux
But as far as I can tell we don't handle these differently in the code. We check the user's OS, then choose the setting for that OS. So I think we could just have r.rpath and r.rterm. This would simplify things for the user (fewer settings) and for our code.
The downside to this change would be that a lot of users would already have those settings set. I think settings can be automatically migrated - I believe this was done recently when the vscode-jupyter extension was split out from the vscode-python extension. I could look into how they did it and see whether it seems practical. If the user has multiple of those settings set, we could show a message to ask them to choose which one to retain.
changed the title [-]Combine platform rterm/rpath settings for different operating systems?[/-][+]Combine rterm/rpath settings for different operating systems?[/+]on Mar 27, 2021
Some users (including me) share vscode settings across multiple operating systems. Does using a unified r.rpath make it impossible to choose different paths on different OSes?
However, platform-scoped settings (as suggested in microsoft/vscode#5595) is not implemented yet.
Using the "machine scope" for these path settings as suggested in #548 might be a solution for this. I'm not sure if this will cover all the different methods of keeping different OSes in sync, but it seems to be the cleanest solution.
We can still keep the os-specifiec settings as overrides, but mark them as "deprecated". This will cause them be hidden if they are not changed by the user. If there are problems with the "machine scope" method, we can keep these settings until the issues are resolved (or possibly indefinitely).
However, platform-scoped settings (as suggested in microsoft/vscode#5595) is not implemented yet.
An issue with platform-scope (which I think is mentioned somewhere in the linked issue) is the fact that some people might use e.g. two linux machines with different R installation paths, so a machine scope is the cleaner solution anyways I'd say.
@renkun-ken Thank you for pointing out the use of the different settings to shared settings across multiple operating systems. I hadn't thought of that so good to hear that there is/was a use case for them.
@ManuelHentschel Thank you for suggesting that approach. It sounds good to me too. Marking the OS-specific settings as deprecated for a while before removing them would give us a good fallback option, as you mention.
Sounds like we are happy with @ManuelHentschel's method. I will have a go at implementing it. (If someone else wants to implement it instead, please feel very free to volunteer.)
Activity
[-]Combine platform rterm/rpath settings for different operating systems?[/-][+]Combine rterm/rpath settings for different operating systems?[/+]renkun-ken commentedon Mar 27, 2021
Some users (including me) share vscode settings across multiple operating systems. Does using a unified
r.rpathmake it impossible to choose different paths on different OSes?However, platform-scoped settings (as suggested in microsoft/vscode#5595) is not implemented yet.
ManuelHentschel commentedon Mar 27, 2021
Using the "machine scope" for these path settings as suggested in #548 might be a solution for this. I'm not sure if this will cover all the different methods of keeping different OSes in sync, but it seems to be the cleanest solution.
We can still keep the os-specifiec settings as overrides, but mark them as "deprecated". This will cause them be hidden if they are not changed by the user. If there are problems with the "machine scope" method, we can keep these settings until the issues are resolved (or possibly indefinitely).
An issue with platform-scope (which I think is mentioned somewhere in the linked issue) is the fact that some people might use e.g. two linux machines with different R installation paths, so a machine scope is the cleaner solution anyways I'd say.
renkun-ken commentedon Mar 27, 2021
Thanks @ManuelHentschel for pointing to machine-scope settings. Provided this, I think it is okay to use unified rterm and rpath then.
andycraig commentedon Mar 28, 2021
@renkun-ken Thank you for pointing out the use of the different settings to shared settings across multiple operating systems. I hadn't thought of that so good to hear that there is/was a use case for them.
@ManuelHentschel Thank you for suggesting that approach. It sounds good to me too. Marking the OS-specific settings as deprecated for a while before removing them would give us a good fallback option, as you mention.
Sounds like we are happy with @ManuelHentschel's method. I will have a go at implementing it. (If someone else wants to implement it instead, please feel very free to volunteer.)
renkun-ken commentedon Mar 28, 2021
@andycraig You may also send PR to vscode-r-lsp and VSCode-R-Debugger since they share the same
rtermandrpathsettings.eitsupi commentedon Sep 19, 2026
I want to implement this before 3.0
feat!: simplify R executable / console path settings (REditorSupport#…