Non default profile settings treats some settings inconsistently when in remote setup #176280
Comments
|
@jvillemure It seems these settings are application scoped settings and they can be read/set only in default profile settings file. Having these settings in the profile settings file will not have any impact. Please let me know if you are seeing otherwise. It would be great if you can provide me a specific example in this case to drill down deeper. |
sandy081
added
info-needed
|
@sandy081 I think it will make things clear if I explain in details my actual use case for using settings profile. An important fact I forgot to mention is that I also use the settings sync feature, since long ago when it was released. I was a quick adopter of settings sync, I really liked the fact that I did not need to manually keep my preferences up to date between the computers I use; especially, I regularly look for and try new settings that comes with new vscode releases or extensions. This saves me a lot of manual work to sync my preferences across my few personal computers, work computer (most of it, like 90%), or other (say, a friend's) computers I would borrow for a specific task. For personal uses, I would always use exactly the same settings and extensions, and settings sync was just perfect for that. In contrast, at workplaces, it has never been the case that I could actually bring my use my own personal settings in the same way as I would at home; sometimes also, there are extensions that find some uses at work, but never at home (and vice versa). I'd expect that this duality home/work is the norm for anyone using vscode at work. There is usually a small subset of my user settings that need to be changed or set to be able to use it at workplace. To make things worst, most of this subset of settings cannot satisfy both homeplace and workplace at the same time and choosing one will imperatively 'sacrifice' the other use. Example of settings: most things related to network, connectivity, telemetry, update settings, etc "http.proxy*": at work, not setting this to the vpn's http proxy basically means I don't receive any upgrades, extensions upgrades, can't build containers, and loose a fair amount of functionality. Conversely, my home computer is not on my work vpn so the proxy does not resolve, so this setting needs to be unset. "remote.SSH.*": in my previous workplace, most settings needed non default values; typically I could also never "dotfiles.repository": need to use corporate git at work, but at home I need my personal github. "dev.containers.defaultExtensions": I don't use the same extensions at home, than those at work, but it doesn't support non default profiles. "dev.containers.repositoryConfigurationPaths": anything with a path in it is subject to change from work to home (although this setting here I can specify an array with paths from both machine, but it's more a workaround). "terminal.external.windowsExec": this one is not really important for my case: is use "wt" anywhere, but again this could potentially differ in an other workplace. Settings sync came long before profile settings, so at that time I had to make a choice form 3 alternatives:
Option 1) is bad since I mostly use vscode at work. Option 2) is actually what I have been doing ever since I start using the experimental 'Settings Profile' feature not long ago. Since I mostly use work computer, and that in the end there is only a rather very small and bounded subset of incompatible settings, option 2) has been good enough for long time and I never envisaged to go back using option 3). So I started using the settings profile feature as it was in the experimental phase, and it did solve well my use case: when hired in a new workplace (with a corporate laptop, or remote desktop), I would bring my own settings, extensions, keybindings, etc which is my default profile. Then if I needed, I create a new work profile by copying my default profile, and change the few settings that are workplace specific. Short story is, I use the settings profile feature because I want to also use the syncing of my settings, extensions, keybindings, etc, but I also want to keep my home settings and extensions independent from my workplace (athough, they would differ in just a few settings and extensions). Additionally, my work profile would always start as a copy of my personal default profile settings, then changing few settings to accommodate the workplace peculiarities or requirements. My settings.json (and the extensions I use) is an accumulation of years of tweaking preferences and it is complete for use of any languages or tasks: I absolutely want to stick to it, and I don't have any uses for things such as 'quickly switch VS Code configurations depending on your current workflow and project' or having 2 vscode windows not using the same profiles (I'm either at work or at home); this was already solved by workspace/folder settings and language specific overrides settings, and actually the current 1.76 behaviour made things more complicated and broke the way I use profile settings (for instance: #176678, #176132). Actually, Settings profile were much better when they were in experimental state. I'd like if we could opt to use the former behaviour (maybe have a setting for this). |
|
@jvillemure Thanks a lot for using settings sync and profiles feature and also explaining your use case for both features. As you also know we have fixed #176678 already and we are discussing about what best we can do to support #176132. Focusing on this issue, can you please let me know what else you are missing or seeing difference from old and current behaviour other than above 2 issues. I am sorry if you already said it and I missed in the previous comment? |
|
This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines. Happy Coding! |
Type: Bug
I use vscode in remote setups wsl, ssh, and devcontainer. I also use a (non-default) work settings profile when I'm at work. Common use of non default profiles would usually include customizing family of settings such as: "http.proxy", "remote.SSH", "dotfiles.", "dev.container". Right now, several of them cannot be applied to non default profiles (for instance most "remote.ssh" settings); and some other settings are applied inconsistently when in different remote setup, specifically, the setting "http.proxy" do not seem to be picked up from a non-default profile when working with a wsl or devcontainer setup, and it seems to be impossible to customize its value in any one of the settings.json files: both in remote settings.json and current profile settings the setting "http.proxy" is inactive and hovering on it displays the message "This setting has an application scope and can be set only in the user settings file.". (In both the above cases, the http.proxy setting could be customized in the default settings profile, but this kind of contradict the main uses of defining non-default settings profile: IMO the first candidate settings that benefit from this feature is http.proxy). I also use an SSH remote setup with my workplace profile settings, but the actual behavior of the http.proxy is totally different from the devcontainer and wsl cases: the http.proxy can be specified in the remote's settings.json (which is a good thing since the remote could have different network settings), but at the same time it cannot pick up the value from the non default profile setttings.json (the setting is inactive with hover message "This setting cannot be applied in this window. It will be applied when you open a local window."), nor does it read the value from the default settings profile (the setting is inactive with 2 messages: "This setting cannot be applied while a non-default profile is active. It will be applied when the default profile is active." and
"This setting cannot be applied in this window. It will be applied when you open a local window".
The only case with predicatble behavior is in non remote setup, the http.proxy setting is picked up from the currently active profile settings.json. This should be exactly what should happen in any kind of remote setup when the remote settings.json file does not overrite the http.proxy setting; also, the http.proxy should be overridable from the remote settings.json file in any remote setup.
VS Code version: Code 1.76.0 (92da948, 2023-03-01T10:22:44.506Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Sandboxed: No
Remote OS version: Linux x64 5.15.90.1-microsoft-standard-WSL2
Remote OS version: Linux x64 5.15.90.1-microsoft-standard-WSL2
Remote OS version: Linux x64 5.15.90.1-microsoft-standard-WSL2
Remote OS version: Linux x64 5.15.0-58-generic
System Info
canvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_renderer: enabled_on
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off
Extensions (22)
(1 theme extensions excluded)
A/B Experiments
The text was updated successfully, but these errors were encountered: