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)

[dbaeumer]

@bpasero, @aeschli FYI.

[bpasero]

https://github.com/Microsoft/vscode/issues/8962

[Tyriar]

8962 is about keybindings, not settings

[sandy081]

Planning for October to Kickoff

[bbkane]

Did this happen? I'd like to consolidate my VSCode settings.json. Great job on the editor, by the way. It's really been a help to me, and the mix of intuitiveness and power makes it easy to recommend to new programmers.

[Tyriar]

@bbkane it got pushed out unfortunately, the issue will be closed with a milestone set (the version it'll land in) when it's done.

[thernstig]

I know you are working hard on all kind of nice features, still, is there any updates on when this might get a new milestone/target release?

[chparimi]

When will this feature release?

[alanlivio]

When will this feature release? [2]

[sandy081]

Its still under discussion, one approach we are thinking is to support Machine specific settings rather than Platform specific. Because most of these settings are path related and they are scoped to a machine rather to platform.

[chris400]

Plattform specific > machine specific I want to place settings on a cloud drive and access it from various machines. In that scenario I would barely benefit from machine specific.

[sandy081]

@chris400 Can you please give me the example of those settings?

[eberkund]

@sandy081 For example, I would like to be able to use a different font on Windows vs Mac OS. Or on Linux I want to use the native title-bar.

I am using the Setting Sync extension so it would be useful if I could share one configuration across all my machines.

[chris400]

@sandy081 https://github.com/Microsoft/vscode/issues/17619 describes it perfectly: the pathes differ on Windows, Linux and macOS.

[thernstig]

@sandy081 There are other settings besides paths, fonts etc. that one might want different per OS. For example "keyboard.dispatch"

I also think settings per OS also fits better since keyboard settings and launch configs have support per OS. So making the normal settings also be per OS would fit better in that sense.

[FelikZ]

There is language specific settings, which allows the following:

{
  "[typescript]": {
    "editor.formatOnSave": true,
    "editor.formatOnPaste": true
  },
  "[markdown]": {
    "editor.formatOnSave": true,
    "editor.wordwrap": "on",
    "editor.renderWhitespace": "all",
    "editor.acceptSuggestionOnEnter": false
  }
}

I suggest to follow up this and allow something like:

{
  "[[osx]]": {
    "editor.fontSize": 13,
    "terminal.integrated.fontSize": 13,
    "markdown.preview.fontSize": 13,
    "restructuredtext.preview.fontSize": 13
  },

  "{windows}": {
    "editor.fontSize": 12,
    "terminal.integrated.fontSize": 12,
    "markdown.preview.fontSize": 12,
    "restructuredtext.preview.fontSize": 12
  },

  "(linux)": {
    "editor.fontSize": 11,
    "terminal.integrated.fontSize": 11,
    "markdown.preview.fontSize": 11,
    "restructuredtext.preview.fontSize": 11
  },

  "editor.fontSize": 12,
  "terminal.integrated.fontSize": 12,
  "markdown.preview.fontSize": 12,
  "restructuredtext.preview.fontSize": 12
}

[jonnyasmar]

@FelikZ Is there a reason you formatted osx, windows, & linux keys differently? Or just illustrating possibilities? I think single brackets are most consistent: [windows]

@sandy081 Platform & machine specific would be great. I'm assuming some pattern like this?

"[windows]: {
  "editor.fontSize": 13,
},
"[Jonny-PC]": {
  "local-history.path": "c:\dev\.vscode",
}

One additional consideration is that terminal.integrated.shell (maybe others?) follows a divergent pattern:

"terminal.integrated.shell.osx": "zsh",
"terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\wsl.exe"

If platform specific settings become an option, this should probably be adjusted to follow the same pattern:

"[osx]: {
  "terminal.integrated.shell": "zsh",
},
"[windows]: {
  "terminal.integrated.shell": "C:\\WINDOWS\\System32\\wsl.exe"
},

[bbkane]

I like the idea of using [] to represent conditions in JSON. Because [language] is already being used as a specialization option, we should consider guarding other names (I'm using sub-maps and the "platform" namespace below"). I also think it would be nice to make the override order explicit.

A theoretical example extending the namespacing with a new key platform and use maps inside to specialize:

{
  // settings later in the list override settings earlier in the list
  "settingsOverrideOrder": [
    "default",           // stuff in settings.json not in a [condition] specialization
    "platform.os",       // settings.json in the "platform.os" map
    "platform.hostname", // settings.json in the "platform.hostnames" map
    "language",          // stuff in the "[lang]" maps
    "project"            // stuff in .vscode/settings.json

  ],

  // We can't do a "language" map cause we need backwards compatibility
  "[elm]": {
    "editor.formatOnSave": true,
  },

  "[platform.os]": {
    "osx": {
      "editor.formatOnSave": true,
    }
  },

  "[platform.hostname]": {
    "mac01": {
      "editor.formatOnSave": true,
    },
    "lin01": {
      "editor.formatOnSave": true,
    }
  },

}

Notes

Instead of scoping by dictionary, we could scope specializations with dots more. This would result in the "hostname" key having dynamically scoped names, which is not great... but it would reduce nesting.

"[platform.os.osx]": ...
"[platform.hostname.mac01]" ... // ewww...

---

We can't have a "[language]": { "elm": ... } specialization because that breaks backwards compatibility. Languages are already represented in "[lang-name]".

---

There's probably better names for a lot of this stuff... "osx" vs "darwin", "settingsOverrideOrder".

"hostname" vs "machineName" vs some other machine identifier (MAC address, IP, ...)

---

I'm namespacing new non-language specializations with dots to avoid language name conflicts (hope there's not a new language named "platform")

---

I'm introducing "settingsOverrideOrder" because I think the user might want to decide override order (particularly in regards to where language fits in).

[FelikZ]

@jonnyasmar for illustration only.

[walter-erquinigo]

I work at Oculus/Facebook and this might be the only feature missing for us to start using VSCode heavily

The proposal

"[platform.os.osx]": ... "[platform.hostname.mac01]" ...

or some regex around it might be fantastic

[chris400]

@chris400 Can you please give me the example of those settings?

I am extending my explanation https://github.com/Microsoft/vscode/issues/5595#issuecomment-459027931: my code sits on a local server, the pathes to the code differs on every plattform.

[mazza]

+1 to desirable feature

A portable/embedded version of Python was compiled to each of those archs In a project I'm working on. The portable environment is used to both run/test the bundled portable software and provide the portable dev env as well. But this missing feature may affect any project intended to be coded in more than one OS.

// settings.json
{
    "terminal.integrated.env.linux": {
        "PATH": ".tools/linux/bin:${env:PATH}"
    },
    "terminal.integrated.env.osx": {
        "PATH": ".tools/macos/bin:${env:PATH}"
    },
    "terminal.integrated.env.windows": {
        "PATH": ".tools\\windows;${env:PATH}"
    },
    "python.pythonPath": ".tools/linux/bin/python3", // (?)
    "python.linting.mypyEnabled": true,
    // "python.linting.mypyPath": ".tools/linux/bin/mypy",
    "python.linting.enabled": true,
    // "python.linting.banditPath": ".tools/linux/bin/bandit",
    "python.linting.banditEnabled": true
}

The commented lines are OK to skip, but if "python.pythonPath" is omitted, VSCode won't find the debuggers and linters. But if it is present it may only work in one OS requiring fix at every time.

The specific way I would suggest in order to require the minimal move to get this done would be to add one more path to settings.json for each arch, so:

• settings.windows.json for Windows
• settings.linux.json for Linux
• settings.osx.json for macOS
• settings.json for all

Then, the OS-specific config file would load after the generic one completing or even overwriting it when convenient. This solution may avoid dealing with infinite possible OS-specific config issues that may arise with many new local solutions.

[rossipedia]

I don't know if this has been said, but platform specific settings are useful for more things than just paths and keybinds. I move between several boxes daily, on all 3 main platforms (Windows, Mac, Linux), and each one needs separate window.zoomLevel settings in order for things to look right.

[RolfNoot]

I have this for example in my settings: "cmake.cmakePath": "/Applications/CMake.app/Contents/bin/cmake", "cortex-debug.openocdPath": "/Applications/ModusToolbox_1.1/tools/openocd-1.0/bin/openocd",

I understand there are issues with some proposed solutions and instead of developers rejecting possible solutions, are there any developers who can propose a solution for this issue?

We're in 2019 and still have to edit settings to switch platforms?

[xahon]

sdelaite uzhe suka

[RuBAN-GT]

@xahon, derzhis, bratishka, ty ne odin

[repentsinner]

Following here from my previous use case regarding python paths on different OSes (https://github.com/Microsoft/vscode/issues/17619#issuecomment-365521276), I also just discovered Shan Khan's excellent Settings Sync and wish that I could keep one sync'd non-workspace settings.json file with separate UI configs for the different machines I work on.

An appropriate "editor.fontSize" is very different on a 13" MacBook vs a 32" 4K Windows machine due to the different display sizes, OS HiDPI scaling methods, font handling, etc.

Having per-host settings would also be awesome, but per-platform settings would get us a good piece of the way there.

Given that Settings Sync has ~1M installs, it seems likely that a good number of people are syncing cross-platform, and certainly cross-host.

Thanks for considering!

{
  "editor.fontFamily": "Fira Code",
  "editor.fontLigatures": true,
  "[macos]": {
    "editor.fontSize": 14
  },
  "[windows]": {
    "editor.fontSize": 13,
    "editor.fontWeight": "300",
    "window.zoomLevel": -1
  }
}

[rossipedia]

@repentsinner I just looked into this again, and it seems as though Settings Sync allows for selectively ignoring certain settings:

// settings.json

{
  // @sync-ignore
  "window.zoomLevel": "1", /* won't upload to gist */
}

I'm not sure that suits your purposes, but I think it'll get me most of the way to where I need to go

[michaeltarleton]

@rossipedia @jarod51, @repentsinner I used your link and noticed you can do per-host, os, env with Settings Sync:

// settings.json on linux

{
  // @sync os=linux
  "window.zoomLevel": "1"
}

// settings.json on a computer with the environmental variable "CODE_ZOOM_1" set

{
  // @sync env=CODE_ZOOM_1
  "window.zoomLevel": "1"
}

// settings.json on "home" computer

{
  // @sync host=home
  "window.zoomLevel": "1"
}

[jcklpe]

I'm honestly kind of surprised that this is still an issue.

The setting sync isn't reliable enough an answer for me. I've had setting syncs revert my settings to months older versions multiple times and I don't consider it reliable enough to solve this problem. This really should be built in.

I mean it's even possible for me to sync my zshrc settings pretty easily as both zsh and bash have really easy OS specific conditional statements possible.

[repentsinner]

Thanks @rossipedia and @michaeltarleton for the heads up on the selective sync stuff.

@sync-ignore does help, although I'd really like everything sync'd and then selectively applied. That might be closer to what Michael found, with everything landing in the gist and then selectively syncing back out to the different VS Code instances. In this case, editing the settings in the gist may effectively result in scoping settings by platform/host/... as only the appropriate settings are sync'd to an instance.

Note that there's some recent activity in https://github.com/microsoft/vscode/issues/78869 that is proposing to move sync into the VS Code project natively.

I didn't intend to derail this issue with sync vs. scoping, and believe they are two separate but substantially related topics. For example, we may also want to use scoped workspace/project settings, where in that case the sync mechanism is git or some other SCM rather than native/extension-based VS Code mechanism.

[xahon]

What the state of this issue?

[hpgmiskin]

We have started using the platform-settings extension for VSCode in order to get different settings for people using different computers. From first testing it seems to work well. We use it to direct to different versions of clang-format.

[sandy081]

This feature has to come to discussions several times and was not considered because it is mainly associated to settings sync. It means, the main use case for this feature is to enable users working on different platforms/machines to share settings per platform. I already started working on providing settings sync feature out of the box in VS Code - https://github.com/microsoft/vscode/issues/2743. So, I also started thinking how to support this. I see two suggestions from the community here:

1. Use language specific settings style. This is thought about and after thinking further we decided not to go with this approach. Reason being language overrides has strong precedence and they can always win against user/workspace/folder settings. This is not intended for platform specific settings. See https://github.com/microsoft/vscode/issues/86737 for more information.

2. Separate platform specific files as mentioned in comment https://github.com/microsoft/vscode/issues/5595#issuecomment-485877346. This way sync will also sync settings appropriately per platform.

Inclined towards 2️⃣ option.

[CodyWalraven]

I really like idea 2, the ability to still have the main settings.json be the base with platform specific files on top that can override just the features you want seems straightforward and simple to use. Plus I think it will be less messy since you are not mixing up all of the different file paths (I'm looking at you windows with your \'s everywhere) in one file.

[sandorex]

The 2nd idea is cleaner IMO and wont add any new syntax to existing settings.json

[xahon]

2020

[yulei900609]

I need this feather very much.

[codecalvin]

Looking forward to this feature. Like 2nd idea.

[Ovyerus]

Seeing how Insiders now has a settings/extensions sync built in without needing another extension to do it, this would be pretty handy to have now

[LeoJhonSong]

Since I am sharing workspace level settings with my members on several platforms, I really need exactly this feature but not a workaround by Settings Sync...

So do we have any news on this feature?

[crscillitoe]

I use different fonts on windows/mac/linux (their font names are slightly different, but they're all the same font).

I have no reliable way to configure the name for each OS right now, can we please get some traction on this feature?

[WilfSilver]

Just been looking through the new documentation for the settings sync in the latest update and came across this, so following on @rossipedia comment, it looks like you can do something similar with the new inbuilt setting sync, by using "settingsSync.ignoredSettings" - still slightly annoying if you are constantly using new computers, though, as I think you would have to continuously update these settings every time. However I think it gets rid of a lot of issues.

EDIT: I have since found two extensions, which I have briefly experimented with, which seems to solve this issue:

• platform-setting by rrunarsf - which allows you to define settings for different platforms, which then are loaded when you boot up VSCode.
• Settings on 🔥! by Eric Biewener - which allows you to quickly toggle settings. I have put this one in because some people might prefer this style of changing settings.

I have also found a third one that seems to be more popular but I haven't experimented with it: Settings Cycler by Cody Hoover - it seems to be similar to the "Settings on 🔥!" extension.

[plzhans]

Looking forward to this feature. Like 2nd idea.

[juarezr]

One question:

This will allow one to have specific settings when switching between local machine and a Remote Container?

What happens when the same .vscode/settings.json is used used in local mode and mapped to a remote container by a devcontainer.json if both run on linux?

[Natetronn]

Would love to see a features like this!

Setting the python interpreter on Linux and Windows over and over again isn't much fun.

[celynw]

I have a temporary solution using the new settings sync (which I love) until this is implemented:

1. Put the setting which is platform-dependent into settingsSync.ignoredSettings.
2. Comments are synced, so next to the ignored settings you can put values you expect into comments up there.
3. On a new machine, copy the setting and a commented line

[Natetronn]

@celynwalters I'm not sure I'm following, would you mind elaborating or sharing some code please?

[celynw]

I have these lines like these at the top of my settings.json, which are synced everywhere. When I sync to a new Linux/Windows/Mac machine, I copy each setting key to the main settings body, with a commented line being a suggestion for its value. Because each setting is not synced you don't have to keep changing it to fight the synchronisation, just set once and forget.

{
    "settingsSync.ignoredSettings": [
        "editor.fontFamily",
        // CaskaydiaCove Nerd Font Mono
        // CaskaydiaCove NF
        "python.pythonPath",
        // /usr/bin/python3
        // C:\Users\celyn\AppData\Local\Microsoft\WindowsApps
        // /usr/local/bin/python3
        "python.condaPath",
        // /scratch/Code/conda
        // C:\\ProgramData\\miniconda3\\condabin\\conda
        // /Users/celyn/miniconda3/condabin/conda
    ],

[Natetronn]

Thanks for the reply.

I see the Settings Sync on Windows (vscode v1.49.0) but, not seeing it on Linux (Manjaro.) It's v1.48.2 and there isn't an update in AUR but, I'll see if I can update manually somehow. I should add, it could missing since I'm using the Code - OSS version and possibly why Setting Sync isn't available; could try the Microsoft Branded bin version, as it is on 1.49.0.

(Setting Sync appears to have be released in 1.48.0: https://code.visualstudio.com/updates/v1_48 - so I should have it on Linux, unless it's a branded version feature only.)

Anyway, this is what I'm missing: https://code.visualstudio.com/assets/docs/editor/settings-sync/turn-on-sync.png

As seen in the Setting Sync docs: https://code.visualstudio.com/docs/editor/settings-sync

While researching Setting Sync, I found this article about the Setting Sync extension, which seems similar to the built in preview version, it would seem. I'll leave it here in case it's helpful:

https://zellwk.com/blog/sync-mac-windows-vscode/

The relevant documentation on the Settings Sync extension's wiki:

https://github.com/shanalikhan/code-settings-sync/wiki/Sync-Pragmas#per-os