Skip to content

Combine rterm/rpath settings for different operating systems? #597

Closed

Description

@andycraig

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.

Activity

  1. changed the title [-]Combine platform rterm/rpath settings for different operating systems?[/-] [+]Combine rterm/rpath settings for different operating systems?[/+] on Mar 27, 2021
  2. renkun-ken commented on Mar 27, 2021

    @renkun-ken
    Member

    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.

  3. ManuelHentschel commented on Mar 27, 2021

    @ManuelHentschel
    Member

    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.

  4. renkun-ken commented on Mar 27, 2021

    @renkun-ken
    Member

    Thanks @ManuelHentschel for pointing to machine-scope settings. Provided this, I think it is okay to use unified rterm and rpath then.

  5. andycraig commented on Mar 28, 2021

    @andycraig
    CollaboratorAuthor

    @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.)

  6. renkun-ken commented on Mar 28, 2021

    @renkun-ken
    Member

    @andycraig You may also send PR to vscode-r-lsp and VSCode-R-Debugger since they share the same rterm and rpath settings.

  7. self-assigned this
    on Sep 19, 2026
  8. eitsupi commented on Sep 19, 2026

    @eitsupi
    Member

    I want to implement this before 3.0

  9. added this to the 3.0.0 milestone on Sep 19, 2026
  10. added a commit that references this issue on Sep 22, 2026
    e2fe2ce
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions