Extension settings should be stored in default location

[cbrnr]

Describe the bug Extension settings are usually located in ~/.vscode/extensions. However, the settings for this extension are stored in ~/.vscode-R.

To Reproduce Here's an example of my setup, all extensions store their settings under .vscode:

~  ls ~/.vscode/extensions
adpyke.codesnap-1.3.4                     ms-python.python-2022.10.0            ms-toolsai.jupyter-renderers-1.0.8
github.vscode-pull-request-github-0.46.0  ms-python.vscode-pylance-2022.7.20    quarto.quarto-1.26.0
julialang.language-julia-1.6.24           ms-python.vscode-pylance-2022.7.30    reditorsupport.r-2.5.0
kevinrose.vsc-python-indent-1.17.0        ms-toolsai.jupyter-2022.6.1101950301

This does not include vscode-R, which has its own folder in my home:

~  ls ~/.vscode*           
/Users/clemens/.vscode:
extensions  argv.json

/Users/clemens/.vscode-R:
tmp  init.R  request.lock  request.log  settings.json

I could try to fix this if people agree this is a bug.

Expected behavior I expected the settings of vscode-R to be in the standard location under ~/.vscode/extensions.

Environment (please complete the following information):

• OS: macOS 11.6.7
• VSCode Version: 1.69.1
• R Version: 4.2.1
• vscode-R version: 2.5.0

[renkun-ken]

For self-managed R sessions, it might not be very convenient to have the files located in the extension folder (e.g. /home/user/.vscode-server/extensions/reditorsupport.r-2.5.0) since it contains the version of the extension. I think this is a main reason we keep such a folder at the moment.

[cbrnr]

I see. Could this be solved in a different way (e.g. creating a symlink if someone wants a self-managed session)? The relevant code snippet could be updated as follows:

configdir = list.files(".vscode/extensions", pattern="reditorsupport*")
if (interactive() && Sys.getenv("RSTUDIO") == "") {
  source(file.path(Sys.getenv(if (.Platform$OS.type == "windows") "USERPROFILE" else "HOME"), configdir, "init.R"))
}

[eitsupi]

I think VSCode Server has a different directory name (.vscode vs .vscode-server). Is there any reason to change the storage location at the risk of it not working?

[cbrnr]

My reasons are (1) it's easier to find the settings folder when it's in the standard location, and (2) I don't like applications cluttering my home directory (I know it's a hidden folder, but still). Of course these reasons might not be enough to warrant the change.

[eitsupi]

See also #495

[cbrnr]

Yes, #495 is very much related! Instead of ~/.vscode-R, if within ~/.vscode/extensions is not an option, you might want to consider using ~/.config/vscode-R instead.

[renkun-ken]

~/.config/vscode-R seems to be a better place.

[benz0li]

Folder ~/.vscode-R is according to requirements – at least for Unix-like operating systems. Nothing wrong with that.

Should this folder be abandoned, do not hard-code ~/.config/vscode-R but follow the guidelines as outlined in https://github.com/REditorSupport/vscode-R/issues/495#issue-765236660 by @LiteracyFanatic.

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[LucasFA]

A backwards compatible change would be to use the XDG locations if they exist (ie, use XDG_CONFIG_HOME/vscode-R/ or fall back to ~/.config/vscode-R/). If neither of those exist, move ~/.vscode-R (if it exists) to XDG_CONFIG_HOME/vscode-R. Of course if the XDG_CONFIG_HOME variable is not set it would fall back to use ~/.config/vscode-R as new default behaviour.

Regarding @benz0li's comment, it is worthy to note that the linked spec explicitly mentions and links to the XDG specification and the Glib conventions, here in the GNOME documentation which also use the XDG spec.

Somewhat related, the wakatime-cli family of extensions are trying to migrate, too. Issue on the main project, the jetbrains extension and the vim extension

Off-topic, but I do not see the value of auto-closing issues. That's like automically tagging it wontfix. An unhandled issue is not intrinsically less worthy than a new issue simply by nature of being older. If this does not reopen it, I will open another one to continue this conversation unless asked not to by a mantainer. Edit: weird. I was pretty sure the stale-bot would reopen the issue by its default settings