Allow local configuration update in the extension API

[dece]

Hello, I would like to see in VS Code the ability to set configuration options without them automatically being written in the target configuration file, whether it's the global settings.json or workspace settings.

Right now it's not possible to share your global/workspace settings between several machines and adding machine-specific configuration options (e.g. window.zoomLevel, due to different screen DPI) without issues. I'm currently writing an extension that will allow users to save some settings in a specific file and load it on top on the user settings ; adding several local files and workspace/folder support can come later once this basic feature is working. If I try to write a locally available configuration option in whatever configuration target with WorkspaceConfiguration.update, the result is automatically written in the associated settings file, making common settings file sharing problematic: the settings file will always store the merged configuration (global & local) from the last machine used.

Proposal:

1. Update current settings with WorkspaceConfiguration.update and an option, or a different kind of ConfigurationTarget, to not write this new configuration setting.
2. Apply the changes only in memory and not on disk : the configuration will be reset next time VS Code is restarted, or when the window reloads.

A quick search in the issues tells me that it would be an appreciated feature:

• Add support for additional global config files (in addition to settings.json) #17634
• Local settings overrides (settings.local.json) #37519
• [Feature] Local Workspace settings #40233

Thank you!

[dece]

Hi, any thoughts or suggestions on this?

[sandy081]

@dece There is an internal support for storing in memory configuration. But this is not supported in the API. But your scenario is a good use case to expose this.

[sandy081]

I'm currently writing an extension that will allow users to save some settings in a specific file and load it on top on the user settings ;

Can you please elaborate more on that and what is the need behind this and how is it helpful to user?

[dece]

Sure! The current idea is to let users specify in their user settings a local setting file, e.g. localSettings.json, accepting the same options as the main setting. When triggered (on startup or on command), the extension would look for this file and load the settings in memory. This way, the user options can be shared between several devices like with the Sync Settings extension or Git and point to a file or symlink storing those local settings so they can vary from one computer to another without impacting the shared configuration. The settings precedence, file management, etc, would be done by the extension so it would require minimal changes from the editor code base as I think exposing this memory configuration option should be just enough.

I use VS Code on several devices and I love the ability to sync my settings, and I think setting a different window zoom level or theme locally would be a great addition.

I don't have much thought on what other use cases for this API support would be, unrelated to my extension, I can just think of configuration preview, but I'm sure extension developers will find something useful to do with this :)

[Airkro]

You are not the only one.
There are many issues like this. not in the same way. but do the same thing.

The point is:
Allow extension to apply vscode configuration without change settings.json(global/workspace/folder)

[Airkro]

Possible forms:

Dynamic way

Provides an API to injecting settings(from anywhere) at vscode runtime. with the highest priority.
Like Dece asking.

Static way

A new Contribution Points in package.json
Then merge below into final configuration. (in sequence):

• Default configuration
• Global configuration
• Extension configuration(defined in contributes)
• Workspace configuration (if available)
• Workspace folder configuration of the requested resource (if available)

This means it can be override by folder settings.

How is it helpful to user:

• the developer (team leader/school teacher/people who use several machines) can define the best settings in Extension Packs (for now, they usually write in readme).
• Anyone can create a Settings Packs
• Someone wants to use it, just install extension. If something wrong, they can disable it.

Why not use the setting sync:

• Not all the settings need to be sync. (drive me crazy)
• In some application scenarios, some settings need to be lock up.
• For some people might be too difficulty.
• Someone just don't want to use gists(for any reason)

[Airkro]

One problems, if make it, how to resolve conflicts from multi Settings Packs.

[dece]

@sandy081 Hi, it's been a year since this issue was opened, any chance of seeing it happening any time soon?

[sandy081]

@dece Sorry no plans yet.

[dece]

No problem I'll look into other ways of reaching my goal. Cheers!

[OmarTawfik]

@sandy081 I'm looking at this for another use case of ours (#87666). I'd love to contribute a ConfigurationTarget.InMemory. Will try to take a stab at it. Any pointers would be appreciated :) otherwise, I'll see if I can submit a PR later.

[sandy081]

There are some open questions to answer before tackling this - How does the user expect to see these in memory settings? So we need to have an UI story first before going into implementation.

[OmarTawfik]

Initially, I suggest the following (open to suggestions/updates as I go through the implementation):

• Add a ConfigurationTarget.Session, taking the highest priority of the existing targets.
• We can have another tab in the settings UI Session, next to User and Workspace.
• As far as the user is concerned, these would be reset with every reload.
• Extensions would be able to edit that without having to touch any files on disk.

Extra things that can be done later (thoughts on priority?):

• Add a command to edit session settings as a JSON (similar to how trusted URLs have their text editor).

This will enable two scenarios. Extensions editing settings temporarily without touching files. And users who might want to change some setting temporarily, without having to git checkout the file later (or polluting their user settings).

[sandy081]

Before going further, can you please elaborate your use case that required this? It would be needed to bring it up with the team.

[OmarTawfik]

• Use case: We need a way for extensions to update settings in memory without needing to touch files on disk. This is to enable this proposed scenario. The suggestion is to use files.include new setting to configure working sets, which can be different between different active windows. So we need to be able to update that setting in memory without affecting other active windows.

cc @bpasero @sandy081

[bpasero]

I do not fully understand why files.include needs to be written into memory and not on disk. I see the desire of being able to write settings for a specific window by not writing into the workspace of that window (e.g. what today's workspace settings do). But can we not simply introduce a new way of writing settings for a window from a file that is living in the user data dir? For example, that file could have the ID of the workspace as hash to be unique and simply serve as another level of settings that contribute to the overall workspace settings.

[sandy081]

But can we not simply introduce a new way of writing settings for a window from a file that is living in the user data dir? For example, that file could have the ID of the workspace as hash to be unique and simply serve as another level of settings that contribute to the overall workspace settings.

This is #40233

[dece]

@bpasero your proposition is interesting but works only for the use case presented by @OmarTawfik. In particular, in-memory settings as described in this issue are not always related to a particular workspace but rather to a VS code user installation.

There are some open questions to answer before tackling this - How does the user expect to see these in memory settings? So we need to have an UI story first before going into implementation.

I'm not familiar with your workflow but my guess is that having some settings set in memory only should be visible and maybe editable in the UI somehow? What about a new tab named "Temporary", "Session" or "Transient" in the settings window?

Before going further, can you please elaborate your use case that required this? It would be needed to bring it up with the team.

Even though my use case described in the OP still holds, another that comes to mind if I'm not mistaken is the Vim VS Code plugin that struggles with rapidly editing some settings that have no purpose being written on files. To quote them:

There are performance implications to using this plugin. In order to change the status bar, we override the configurations in your workspace settings.json which results in increased latency and a constant changing diff in your working directory.

Source: https://github.com/VSCodeVim/Vim#vim-airline

[andyearnshaw]

Even though my use case described in the OP still holds, another that comes to mind if I'm not mistaken is the Vim VS Code plugin that struggles with rapidly editing some settings that have no purpose being written on files.

This is what I came here to request this feature for. I'd love to use this feature of VSCodeVim, but it is just too heavy on performance. If extensions could do in-memory overrides of specific configuration properties, that would solve this problem.

[alexandermckay]

The airline feature in VSCode Vim is border line unusable without the ability for the extension to modify vscode configuration without changing settings.json

[VergeDX]

macOS + Nix (nix-darwin) users may need this feature.

When we manage settings.json by using nix, the config file is readonly,
this means vscode cannot save current theme config (workbench.colorTheme),
so vscode theme switch by follow system apparence, but cannot persisit.

If I write a extension, switch current theme on vscode launch, the issues above will gone.
But I can't, I cannot modify the config in memeory. And my settings.json is readonly : (

[phryneas]

Same for NixOS and https://github.com/nix-community/home-manager on any operating system.

[vscodenpa]

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding, and happy coding!