Allow local configuration update in the extension API

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:

• https://github.com/Microsoft/vscode/issues/17634
• https://github.com/Microsoft/vscode/issues/37519
• https://github.com/Microsoft/vscode/issues/40233

Thank you!

[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.

[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