Fine-tune `DeleteSettingsFileUponExit` or get rid of it

[kAlvaro]

This is a follow-up to #2. I've been trying the DeleteSettingsFileUponExit setting for a couple of weeks and I don't think it's useful. I reckon it either needs a completely different implementation or to be removed altogether.

I found it's quite dangerous because it always removes the settings files, even if it wasn't created at a consequence of the extension action. That means that it steadily removes all the workspace settings in your hard disk as you work with them. Considering it's just a workaround for an annoying yet relatively minor issue, it's definitively not worth it.

I'm not fully sure if it's the expected behaviour. I had initially assumed that it would only remove the file if it had created it in the first place and that the warning about losing customisations referred to those made in that session. However, now I've re-read the explanation carefully I think it's warning about the exact behaviour I'm suffering: every time I open an existing workspace its settings disappear.

[stuartcrobinson]

ok just to clarify & make sure i understand,

the use case for adding the setting was this:

Global setting is saved, like a custom sidebar color. when no extension is used, then the sidebar color is changed for each workspace, but no .vscode/settings.json file is generated. when the WindowColors extension IS used, however, for some reason VSCode annoyingly saves that global setting to the workspace .vscode/settings.json file. this needless addition prevents WindowColors from deleting .vscode/settings.json because it sees that it contains a setting it doesn't recognize. the only way to prevent .vscode/settings.json files from being saved in opened workspaces in this case is just to delete the file upon exit, regardless of contents.

^ that's what i found when using WindowColors with a global color customization.

it seems useful to me as it's the only way to prevent workspace settings files from being saved when you don't want them.

i'm assuming this was useful for you sometimes, but then dangerous other times? like, you have some workspaces that you DO want custom configurations for, but this was deleting them?

my question is: what is the use case for when this setting was damaging for you?

i'm wondering if it's better to remove this setting, or just make the description more clear

[kAlvaro]

I have a strong feeling that we're not understanding each other because I don't think I have a rare use case. I want to get unique window colours in Visual Studio Code when I open a folder (so far so good). I take advantage of VS Code's loose concept of workspace:

1. Every web site I code is located in its own folder. These workspaces are heavily customised so they have a .vscode directory that contains settings, tasks, etc. (A typical IDE would call that a "project").

2. I sometimes open random directories (either local or in network shares) just to have quick access to files I need to check (e.g. C:\Apache24\logs). There's nothing to customise there. (A typical IDE would never venture there).

The initial release of the extension would create .vscode directories all across my hard disk and local network due to use case nr. 2. Since it's apparently not possible to change the window colours without writing them to settings.json you proposed to remove the .vscode folder afterwards whenever it contained nothing but the settings set by the extension. However that didn't work if you already have user-level colour customisations of any kind because they got merged with the extension's. So you proposed a setting that would delete the .vscode unconditionally. That means that in practice you need to pick one:

• "windowColors.🌈 DeleteSettingsFileUponExit": true interfering with use case nr. 1 because project settings get wiped out.
• "windowColors.🌈 DeleteSettingsFileUponExit": false interfering with use case nr. 2 because disks get full of unwanted .vscode directories.

I hope I've been able to explain myself.

[stuartcrobinson]

sorry for delay here, still waiting for chance to get back to this

[stuartcrobinson]

Hi Álvaro - sorry for the huge delay and thank you for your detailed explanation. I just published an update that automatically deletes the settings files unless it has non-windowsColors settings saved to it.

I also removed the DeleteSettingsFileUponExit option as you suggested. Thinking that if it turns out that anyone actually wants to keep the colors in the settings file (to save specific colors to git or something) then i'll add it back.

Let me know what you think, and how this new version works for you?

[stuartcrobinson]

false alarm. new version had trouble in windows so i've reverted for now.

[kAlvaro]

Ah, alright, I was scratching my head so far because I wasn't getting colours in non-project Windows and extension commands triggered error messages xD