arnaud-lecat commented 8 years ago

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 commented 8 years ago

@bpasero, @aeschli FYI.

bpasero commented 8 years ago

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

Tyriar commented 6 years ago

8962 is about keybindings, not settings

sandy081 commented 6 years ago

Planning for October to Kickoff

bbkane commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

When will this feature release?

alanlivio commented 5 years ago

When will this feature release? [2]

sandy081 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

eberkund commented 5 years ago

@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 commented 5 years ago

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

thernstig commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@jonnyasmar for illustration only.

walter-erquinigo commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

+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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

sdelaite uzhe suka

RuBAN-GT commented 5 years ago

@xahon, derzhis, bratishka, ty ne odin

repentsinner commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

What the state of this issue?

hpgmiskin commented 4 years ago

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 commented 4 years ago

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:

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.
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 commented 4 years ago

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 commented 4 years ago

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

xahon commented 4 years ago

2020

yulei900609 commented 4 years ago

I need this feather very much.

codecalvin commented 4 years ago

Looking forward to this feature. Like 2nd idea.

Ovyerus commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Looking forward to this feature. Like 2nd idea.

juarezr commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

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

Natetronn commented 4 years ago

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

celynw commented 4 years ago

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 commented 4 years ago

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

microsoft / vscode

Allow to scope settings by platform #5595

8962 is about keybindings, not settings

Notes