Simplify vscode-r for new users

[ElianHugh]

Is your feature request related to a problem? Please describe.
The transition to vscode-r may be difficult and daunting for new users. For instance, vscode-r has a lot of customisation through the settings menu. However, the depth and breadth of customisation can be daunting to new users. I see @ManuelHentschel has taken steps to improve this with the r.rpath change (great idea by the way), but I think we could do some work to help simplify setup further. I have some ideas for this, but I would like to hear everyone's thoughts.

Describe the solution you'd like
Some ideas I've had:

• Group vscode-r settings by their broad purpose. For instance, rmarkdown settings, workspace viewer settings, and help panel settings could be grouped or sorted together. At present, as these settings are not grouped, they are sandwiched in between setup settings like rterm and rpath. We could group these under something like 'General' or 'Editor'. We could have rterm, rpath, rterm send delay (and other similar settings) grouped under 'Advanced'.
• Potentially collapse R LSP Client into vscode-r, and group its settings as per above
• Potentially enable session watcher by default? I understand that the session watcher is experimental in nature, but it has been some time since its release (nearly a year). I haven't noticed any bugs with it lately, but that might just be my experience. Given the important abilities of the session watcher, it seems to me that new users would likely want this setting on, even when they don't know what the session watcher is/does.
• Potentially simplify the readme/landing page (i.e. https://github.com/Ikuyadeu/vscode-R). At present, it is a lot of information to digest for a new user, and doesn't explain how to get the extension working. It might be useful, for example, to format the page as:

Requirements
Installation
Features
Settings
etc...

... and then have links to wiki pages for more in-depth information. I also think it would be a lot less information-overload if we went without the pictures, but that might just be personal preference.

[ManuelHentschel]

Group vscode-r settings by their broad purpose. For instance, rmarkdown settings, workspace viewer settings, and help panel settings could be grouped or sorted together. At present, as these settings are not grouped, they are sandwiched in between setup settings like rterm and rpath. We could group these under something like 'General' or 'Editor'. We could have rterm, rpath, rterm send delay (and other similar settings) grouped under 'Advanced'.

Agree, though we shouldn't change this around too often, since (as far as I'm aware) there is no mechanism for "renaming" settings, so users will have to specify all their settings again after we change the names.

Potentially enable session watcher by default? I understand that the session watcher is experimental in nature, but it has been some time since its release (nearly a year). I haven't noticed any bugs with it lately, but that might just be my experience. Given the important abilities of the session watcher, it seems to me that new users would likely want this setting on, even when they don't know what the session watcher is/does.

I think this could be done safely for terminals launched using R: Create R Terminal since users don't (or shouldn't) expect a vanilla R session for terminals launched via the extension.

... I also think it would be a lot less information-overload if we went without the pictures, but that might just be personal preference.

I definitely agree. I think the readme would look a lot more structured if we went without the pictures or moved them to a separate section towards the end of the page. Also, it might help to replace the current pictures with a more "organized" collection.

[Ikuyadeu]

Thank you for summarizing current managing problems. All of them are important. Almost I agree with @ManuelHentschel

Potentially collapse R LSP Client into vscode-r,

Once, I freeze that discussion on #98 to considering copyright managing.
To continuing to manage this project, I'm discussing with a For-profit organization.
I will announce the result after the discussions are progressing.

Potentially simplify the readme/landing page (i.e. https://github.com/Ikuyadeu/vscode-R).

I agree with you. I believe the making R Tutorial page will help new users like the Python extension Tutorial.
https://code.visualstudio.com/docs/python/python-tutorial
Now, I'm writing that in my mother language by 12/24. After that, I want to share the English version with you.

[ElianHugh]

Agree, though we shouldn't change this around too often, since (as far as I'm aware) there is no mechanism for "renaming" settings, so users will have to specify all their settings again after we change the names.

@ManuelHentschel
That was my concern too. I had a quick look around and didn't find anything on it, so I suspect you're right. I guess we could have a hacky conversion function to correct the old settings? E.g. r.workspaceViewer.bla -> r.editor.workspaceViewer.bla

Edit: carrying on with the above, we could have a message box pop up if it detects old settings, and asks if the user wants to convert to the new settings

I think this could be done safely for terminals launched using R: Create R Terminal since users don't (or shouldn't) expect a vanilla R session for terminals launched via the extension.

Makes sense to me!

I definitely agree. I think the readme would look a lot more structured if we went without the pictures or moved them to a separate section towards the end of the page. Also, it might help to replace the current pictures with a more "organized" collection.

I like the organised collection idea, some way of making them uniform would go a long way.

Once, I freeze that discussion on #98 to considering copyright managing.
To continuing to manage this project, I'm discussing with a For-profit organization.
I will announce the result after the discussions are progressing.
Now, I'm writing that in my mother language by 12/24. After that, I want to share the English version with you.

@Ikuyadeu
Great! Thank you for the heads up. I look forward to seeing your progress!

[ManuelHentschel]

That was my concern too. I had a quick look around and didn't find anything on it, so I suspect you're right. I guess we could have a hacky conversion function to correct the old settings? E.g. r.workspaceViewer.bla -> r.editor.workspaceViewer.bla

Edit: carrying on with the above, we could have a message box pop up if it detects old settings, and asks if the user wants to convert to the new settings

I implemented a message box like this in the debugger when moving the settings of the debugger:

https://github.com/ManuelHentschel/VSCode-R-Debugger/blob/38490254e0f5281e61fa9dac03bfc7206f9f38bc/src/extension.ts#L25:L29

I wouldn't try to update the settings automatically though, since vscode uses a combination of settings from different places (global user settings, workspace settings, language-specific settings, ...) which would be quite difficult to handle properly.

[ElianHugh]

That was my concern too. I had a quick look around and didn't find anything on it, so I suspect you're right. I guess we could have a hacky conversion function to correct the old settings? E.g. r.workspaceViewer.bla -> r.editor.workspaceViewer.bla
Edit: carrying on with the above, we could have a message box pop up if it detects old settings, and asks if the user wants to convert to the new settings

I implemented a message box like this in the debugger when moving the settings of the debugger:

https://github.com/ManuelHentschel/VSCode-R-Debugger/blob/38490254e0f5281e61fa9dac03bfc7206f9f38bc/src/extension.ts#L25:L29

I wouldn't try to update the settings automatically though, since vscode uses a combination of settings from different places (global user settings, workspace settings, language-specific settings, ...) which would be quite difficult to handle properly.

Right! Your deprecated settings message seems perfect for something like this. I completely forgot about the combination usage of settings, so I agree with your assessment re: automatic updating. I guess the main issue is more deciding what to group the settings under. I think ideally we would have "advanced" settings at the end, with the general/editor specific settings shown first (a minor issue is that settings are sorted alphabetically, so 'advanced' might be the wrong name to go for). I think this would be ideal as:

1. new users may not understand the purpose of advanced settings (e.g. rterm)
2. new users may not have a use for the advanced settings
3. many of the advanced settings automatically resolve without input (e.g. rpath finding the R executable)

Looking over the current settings available, I think there are a few broad settings categories (the names are mainly for illustration) which we could condense or split up depending on how specific we want to be:

• Document Settings: those that affect R document appearance/functionality
  • Rmarkdown: Chunk background colour
  • Rmarkdown: Code Lens Commands
  • Rmarkdown: Enable Code Lens
• Functionality Settings: those that affect the various views, webviews, and extra functionality implemented
  • Help Panel: Enable Syntax Highlighting
  • Help Panel: Help Provider
  • Session Watcher
  • Workspace Viewer: Remove Hidden Items
• Integrated Terminal Settings: those that affect the R terminal
  • Always use active terminal
  • Bracketed paste
  • Source: encoding (could fall under document)
  • Source: focus (could fall under document)
  • Rterm: delay (could fall under executable)
• Executable Settings (could also name it 'R Sessions', in-line with RStudio): those that affect the R executable
  • Rpath
  • Rterm
  • Rterm: Option

These are pretty roughly grouped, but I thought it might be good to try to narrow what they'd fall under. I tend to think more specificity is better in the long run, especially with long-term upkeep of the codebase. Otherwise, I think we could end up in a similar situation down the road.

[eitsupi]

FYI

I think VScode Remote-Containers is very useful for trying out a new language because it absorbs the differences between OS by using Docker and automates the vscode setup. So I have changed the R container definition files which are able to added by Remote-Containers extention(microsoft/vscode-dev-containers#732).

The R container definition files had not been updated for about 2 years though, I hope to update it appropriately and I hope that it will be an option for new users to try vscode-R in the future.