Allow to scope settings by platform

[jarod51]

Hi

I develop on 3 different platform. When synchronizing settings, snippets and so on, i often must change path, adjust font-size, etc...

So, it could be great if we had a per platform settings set (Windows, Mac, Unix)

[wolf99]

Possibly this issue should be closed in favor of #116740 so as to "centralize" support and effort ?

[kankaristo]

Possibly this issue should be closed in favor of #116740 so as to "centralize" support and effort ?

That looks like a possible way to implement support for per-platform settings, but other than that, it looks like a different (and broader) feature, with a different set of requirements. I would expect per-platform settings to be automatic, instead of having to manually switch profiles.

I'm also not sure how syncing those profiles would work in practice. Would the current profile also be stored in the settings JSON? If so, it would be synced like any other setting, and it would essentially break per-platform settings: computer A should permanently use profile A (e.g. Linux settings), and computer B should permanently use profile B (e.g. macOS settings). Under other circumstances, syncing the used profile across computers might be preferable, but not here.

And as a last minor thing, an issue number of 5595 (vs. the much larger 116740) immediately tells that this is a long-awaited feature. So, until GitHub (finally) has some proper "issue popularity" feature, it would hurt the visibility of this issue, if it were closed in favor of a much more recent issue.

[nebbles]

until GitHub (finally) has some proper "issue popularity" feature

If you count 👍 reactions as upvotes (which many deem the unofficial way of voting/showing support) then sorting by that reaction shows this issue is 14th in popularity for this repo

Plus from my view, user profiles are trying to solve a different problem to platform-specific settings. I would imagine there are plenty of people quite content with just one profile, but just may have to use multiple platforms. Or others (in the case I outlined above) where the vscode settings are shared with the repo and we have contributors using different platforms that should have the repo automatically configured to work for them out the box.

[medo64]

Due to different font rendering between platforms (in my example Windows 10 and Ubuntu 22.04), for some fonts I need a different font weight to get the same look and feel. Having per-platform fontWeight (and, god-forbid, other font related settings) would solve this problem neatly.

But I doubt this corner case will move the scales when other examples in the previous 5 years didn't...

[cwensley]

This has been a bane of our existence enough times that it made me have to comment on another use case with no workaround. We use the C# extension and have different .sln's to use based on platform. On the other platform(s) we need to manually select the project every time, which is simply a waste of time..

{
    "omnisharp.defaultLaunchSolution": "path/to/windows.sln", // on Mac or Linux you need to select the correct sln every time.
}

Please, please implement this feature. We can't have all plugins implement a way to have different settings per platform, it is wasted effort when it can be implemented globally.

[MatrixRanger98]

I need this feature, too. Please implement it soon. It should be implemented globally as with per platform keybindings.

[thernstig]

@sandy081 @kieferrm in 2016 User Voice was retired. Github reactions replaced this functionality to gauge user interest of new features.

https://code.visualstudio.com/blogs/2016/08/19/goodbyeuservoice

This is voted top 12 of all users requests currently. Is there any chance prioritization could honor the use of reactions, for issues that I guess are fairly straight forward to implement? Why this specific issue is important is that it is a real problem for many users, not just a "nice to have".

Disclaimer I understand asking for prioritization considerations can be frowned upon and if so, I preemptively apologize. You are doing an amazing job nonetheless I and do understand if you prioritize otherwise. After all, most of us are developers that understand prioritization has nuances not always visible to external users.

[JRHeaton]

This is super silly to be continuously asking at this point. It's likely trivial for the core devs and I speculate the only reason it's de-prioritized or ignored outright is that they're all using a single platform (Windows). I think we should dupe this issue multiple times to gain traction on it. Just like with Apple's radar/bug reporting system where you can refer to an existing issue/ticket and dupe it, I think we should do the same on GitHub here so that this gets implemented. Otherwise I'm waiting, and have been for over a year, to hear the rationale from the dev team as to why they would purposely not implement it. At least be transparent about receptoin and potential timelines and priorities.... anyone else with me?

[ooobii]

Not sure why this isn't being worked on. How can we escalate this issue to the developers? Especially when switching between Windows & Unix environments where path specifications are different, this is a seriously troubling issue...

[piotrku]

I came here today and I'm kind of surprised that so many people has this problem for so long and nothing happens, and even more that solving it does issue not require any significant amount of work :(

[AbdulAbCellera]

Sorry to spam everyone but could this solve our issue? https://code.visualstudio.com/updates/v1_69#_settings-profiles

[nickmccurdy]

Is there a way to automatically set a profile based on the platform?

[michaelmarziani]

I have a similar use case with a mixed dev environment. This feature would save a good bit of confusion and frustration.

[sailor103]

This is a great feature if vscode can support it, now I have to ues different github users.

[Commybwans]

This is a great feature if vscode can support it, now I have to ues different github users.

[sanyer]

@AbdulAbCellera this looks exactly like a perfect solution and even more!

[deividrvale]

I'm searching around on how to solve the exact same problem. But I need to set some paths on the .json config file... and you probably guessed it right if you guess was that they are different between Linux/Mac/Windows.

It seems the feature isn't implemented yet even after so many years.

Very sad.

[Cielquan]

This feature seems to be implemented as beta in the insiders version since last month. You may want to have a look at that.

See comment above: https://github.com/microsoft/vscode/issues/5595#issuecomment-1178497520

Sorry to spam everyone but could this solve our issue? https://code.visualstudio.com/updates/v1_69#_settings-profiles

[ryuukk]

6 years still nothing

bloated product and yet can't do basic things like per os config, for a crossplatform tool, shame on microsoft

[mikew]

I don't think Profiles really solve this. It copies your whole settings and then keeps them separate. So for me, who has 200 odd lines of settings across 3 platforms, it's now 600 lines of settings overall. And if you want a change to apply to all profiles, you have to manually switch to it, change it, then change back.

I just want to say "Windows should use native title bars", not manage and switch between N separate profiles. Seems like this should be the interface for each VS Code settting:

type VSCodeSetting<T> = T | {
  windows: T
  osx: T
  linux: T
}

[deividrvale]

I don't think Profiles really solve this. It copies your whole settings and then keeps them separate. So for me, who has 200 odd lines of settings across 3 platforms, it's now 600 lines of settings overall. And if you want a change to apply to all profiles, you have to manually switch to it, change it, then change back.

I just want to say "Windows should use native title bars", not manage and switch between N separate profiles. Seems like this should be the interface for each VS Code settting:

type VSCodeSetting<T> = T | {
  windows: T
  osx: T
  linux: T
}

This describes exactly what I wanted.

[autoferrit]

don't get me wrong, the new profiles feature is pretty nice. But I agree that it copying the config is really cumbersom. why not have a base config and the other profile has a parent it inherits from and only implements the changed config items? That alone would probably make profiles work.

Beyond that, I have to tell vscode settings sync to ignore completely the important config items. which isn't a small amount. At least theres specific platform config for some items, but those are mostly because plugin authors have made those per platform config items, not native to vscode.

Granted I think

bloated product and yet can't do basic things like per os config, for a crossplatform tool, shame on microsoft

is a bit much as it seems like most editors have some kind of issue with cross platform configs, even the IntelliJ stuff. Mostly that's not as much of an issue with terminal-based editors like vim and emacs. But those are a different ballgame anyways.

One idea, would be that if any config was just prefixed with the platform, or hostname, then it would only apply on that one platform/hostname. but using the blocks like [python] -> [darwin] would be far better

[xenoterracide]

honestly, I would like a per computer setting, nothing guarantees a path, for example, will be the same if I switch computers even if they are on the same platform.

I use asdf, and it installs to my home directory. The eslint extension requires a custom node runtime to have an absolute path. Since I have settings sync on, that directory is synced to each machine. I don't know that profiles help because I would have to have a profile per computer or something.

By platform isn't really the right solution either

[julianxhokaxhiu]

Came here for the very same request. Kindly asking if it's possible to be considered by the VSCode team. Or if possible, let me know of how can I support different settings on different platforms, for eg. CMake Tools.

[scmx]

A work-around could be to generate the file to be correct for the platform. Here's one specific way for a use-case I had.

VSCode settings.json typescript.tsdk double backslash windows workaround Next.js https://gist.github.com/scmx/de7564c9efebaec108cfb74e83ec9d1b

[starball5]

how can I support different settings on different platforms, for eg. CMake Tools.

If you want to change CMake configuration, just use CMake presets with its condition field. Ex. "condition": {"type": "equals", "lhs": "${hostSystemName}", "rhs": "Darwin"}.

[julianxhokaxhiu]

@starball5 thanks, in the end I eventually migrated to CMake Presets on the project i was requiring this and now I'm unblocked. Also this seems the way to go, so it's not only VSCode related but it supports the entire CMake ecosystem :)

[starball5]

Related on Stack Overflow:

• How can I have multiple platform-specific workspace settings.json files? Is it possible?
• Synchronizing Visual Studio Code configuration between Windows and Linux with dynamic path handling

[assiless]

suggestion

this is much better

"terminal.integrated.defaultProfile.windows": "Command Prompt",
"terminal.integrated.defaultProfile.linux": "zsh",

for clangd the default

"clangd.path": "C:\\..\\clangd.exe", # only for 1-os

inspired by the top

"clangd.path._windows": "C:\\Program Files\\LLVM\\bin\\clangd.exe", // for windows only
"clangd.path._linux": "/opt/clang/bin/clangd", // for linux only
"clangd.path._osx": "/opt/clang/bin/clangd", // for osx only

"clangd.path": "clangd", // for default/fall-back
"clangd.path._linux": "/opt/clang/bin/clangd", // for linux only

[emmenlau]

@assiless I'm not sure what you are saying. Does this work now?

[znorman-harris]

As an extension developer, minimally we should have the ability to set platform, just like scope, for preferences in package.json files. Maybe something like this:

[Poikilos]

Here's a good use case: Using ShellCheck shows a linting error when the file contains "\r" characters (such as in Windows which uses "\r\n", or macOS <= 9 which uses "\r"), but git is usually (such as in GitHub Desktop and Git Cola) set to check out newlines using the platform's newlines but commit using "\n" (Therefore there isn't actually lint). Therefore to prevent Windows users from seeing every line as having an error in ShellCheck, the following setting should only be for win32:

"shellcheck.exclude": ["1017"],

• If set for every OS, it could potentially hide actual lint on macOS and Linux-based systems. Therefore the linting error should only be excluded on win32.

[gueggel]

Any news? This would be a great and really helpful feature.

[pouyarezvani]

Just use Intelij guys 😁

[philipbel]

Well, it's been 7 years, 5 months and 25 days since this issue was posted.

[ievgennaida]

Would be nice to have python venv based on envrionment: "python.defaultInterpreterPath": "~/venv/bin/python"

[TryerGit]

This will be a huge time saver and boost to productivity. Settings sync does not solve the issue. See stackoverflow discussion on that here

Currently, I have to manually manage the following various versions of settings.json:

Windows Machine 1:

    "hsnips.hsnipsPath": "C:\\Users\\TryerGitOne\\AppData\\Roaming\\Code\\User\\hsnips",

Windows Machine 1, WSL: 

    "hsnips.hsnipsPath": "/mnt/c/users/TryerGitOne/AppData/Roaming/Code/User/hsnips",

Windows Machine 1:

    "vim.neovimPath": "C:\\Users\\TryerGitOne\\Downloads\\nvim-win64\\Neovim\\bin\\nvim.exe",
    "vim.vimrc.path": "C:\\Users\\TryerGitOne\\.vimrc",
    "hsnips.hsnipsPath": "C:\\Users\\TryerGitOne\\AppData\\Roaming\\Code\\User\\hsnips",

Linux: 

    "vim.neovimPath": "/usr/bin/nvim",
    "vim.vimrc.path": "/home/TryerGitOne/GoogleDrive/research_programming/Setup Folder/VSIDE Stuff/.vimrc",
    "hsnips.hsnipsPath": "~/.config/Code/User/hsnips",

Windows Machine 1:

    "vim.neovimPath": "C:\\Users\\TryerGitOne\\Downloads\\nvim-win64\\Neovim\\bin\\nvim.exe",
    "vim.vimrc.path": "C:\\Users\\TryerGitOne\\.vimrc",
    "hsnips.hsnipsPath": "C:\\Users\\TryerGitOne\\AppData\\Roaming\\Code\\User\\hsnips",

Windows Machine 2:

    "vim.neovimPath": "C:\\Users\\TryerGitTwo\\Downloads\\nvim-win64\\bin\\nvim.exe",
    "vim.vimrc.path": "C:\\Users\\TryerGitTwo\\.vimrc",
    "hsnips.hsnipsPath": "C:\\Users\\TryerGitTwo\\AppData\\Roaming\\Code\\User\\hsnips",

Windows Machine 1:

    "vim.neovimPath": "C:\\Users\\TryerGitOne\\Downloads\\nvim-win64\\Neovim\\bin\\nvim.exe",
    "vim.vimrc.path": "C:\\Users\\TryerGitOne\\.vimrc",
    "hsnips.hsnipsPath": "C:\\Users\\TryerGitOne\\AppData\\Roaming\\Code\\User\\hsnips",

Windows Machine 2, WSL: 

    "vim.neovimPath": "C:\\Users\\TryerGitTwo\\Downloads\\nvim-win64\\bin\\nvim.exe",
    "vim.vimrc.path": "C:\\Users\\TryerGitTwo\\.vimrc",
    "hsnips.hsnipsPath": "/mnt/c/users/TryerGitTwo/AppData/Roaming/Code/User/hsnips",

You can easily see the combinatorial madness. Many of these machines (even Windows machines) are official machines where the user does not have the option of providing the same username as all other machines so that the directory paths may be the same.

Vim already provides for this in .vimrc. Here is an example from my single .vimrc where based on running a shell command (query present working directory), one can figure out which machine mount one is on:

let g:machine_run_on_wsloffice = system("pwd | grep -c '/mnt/e'")
let g:machine_run_on_wslhome = system("pwd | grep -c '/mnt/c'")
if g:machine_run_on_wsloffice == 1
  set viminfo=%,<800,'100,/50,:100,f1,n./.vim/.viminfooffice
else
  if g:machine_run_on_wslhome == 1
    set viminfo=%,<800,'100,/50,:100,f1,n./.vim/.viminfohome
  else
    set viminfo=%,<800,'100,/50,:100,f1,n./.vim/.viminfoubuntu
  endif
endif

So, there is no need to have a different .vimrc for different machine. As others have pointed out, CMake has support for something similar also.

[tn-072]

What about this:

{
    // ...
    "[sys:win]": {
            "python.defaultInterpreterPath": "<my python path on windows>",
    },
    "[sys:linux]": {
            "python.defaultInterpreterPath": "<my python path on linux>",
    },
    "[sys:osx]": {
            "python.defaultInterpreterPath": "<my python path on Mac>"
    },
    // ...
}

which uses similar syntax like language-specific settings:

{
    // ...
    "[cpp]": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "llvm-vs-code-extensions.vscode-clangd",
    },
    // ...
}

[sdholden]

Some sort of solution is long overdue...any progress?

[buzcarter]

I'll second @tn-072 's suggestion.

{
    "editor.fontSize": 14,
    "python.pythonPath": "/usr/local/bin/python3",
    "[windows]": {
        "editor.fontSize": 16,
        "python.pythonPath": "C:\\Python39\\python.exe"
    },
    "[mac]": {
        "editor.fontSize": 18,
        "python.pythonPath": "/usr/local/bin/python3"
    },
    // ... the shared bits
}

[sanmai-NL]

Instead of scoping by 'platform' I suggest to scope by user-defined tag(s), to support use cases where the same OS is used for different purposes (e.g. work Linux, personal Linux) beyond what profiles can offer.

[heartacker]

Instead of scoping by 'platform' I suggest to scope by user-defined tag(s), to support use cases where the same OS is used for different purposes (e.g. work Linux, personal Linux) beyond what profiles can offer.

What you say is profile

[sanmai-NL]

Then all combinations of language, macOS/Linux/Windows, work/personal would need to be separate profiles.

[starball5]

I ctrl+f-ed for "profile" and several times when the profiles approach came up in past discussion, it was dismissed because at the time, it required creating a standalone copy of settings, and there was no way to inherit from the default. For those people, see #156144, which as released in July 2023. I'm not saying this is the solution. I'm just saying it may be more attractive as a workaround than it had been previously.

[jd-solanki]

Why it's still in backlog?

[pfeerick]

I'd love to see this feature for the some of the above reasons such as OS and path specific differences, but also because I set the new option

"terminal.integrated.middleClickBehavior": "paste"

which works great on Windows, but on Linux (which picks up the setting because I have Settings Sync enabled), it makes it paste the clipboard content + selection rather than just the selection, so I've had to set it back to default now. :rofl:

[starball5]

@pfeerick oh interesting. Are you aware of "editor.selectionClipboard": false,? See also https://stackoverflow.com/q/36723333/11107541

[Poikilos]

Then all combinations of language, macOS/Linux/Windows, work/personal would need to be separate profiles.

If you have a work and personal account on your linux/macOS/Windows machine, that is 6 accounts. If you need it that fine-grained, you could already just put the setting in your user profile. It isn't directly related to this. There is no way to detect if you are work or personal...that is a user-level abstract distinction.

[pfeerick]

@pfeerick oh interesting. Are you aware of "editor.selectionClipboard": false,? See also

No I wasn't... thanks for that!. It fixes the "double" paste (one from selection, one from clipboard), but does mean you must use the clipboard if using middleClickBehavior": "paste", so still not ideal. Spotted terminal.integrated.copyOnSelection as well though which I didn't know about... that would work if just working with terminal, and not wanting to mix editor and terminal.

[alexchexes]

In the meantime (the discussion has lasted 8 years and doesn't seem to be progressing), how do you all set a comfortable font when switching machines? On my MacBook, I'm good with a 12px font, but on my Windows machine, I need at least 14px. What do you do in such cases (when Settings Sync is On)?