Ignore Upload some settings information in GIST

[borekb]

Originally from #100 (comment)

Since #100, local settings can be replaced by replaceCodeSettings. However, this doesn't influence upload direction at all and if something changes frequently, there will be lots of new versions in the Gist for no good reason.

It would be good if replaceCodeSettings could also be taken into account during upload and replace the real value with some placeholder or something.

[rainbyte]

I think this would be useful, e.g.:

• desktop vscode usually has "window.zoomLevel": 2
• on my notebook I prefer "window.zoomLevel": 0

It would be better to just ignore that setting.

[shanalikhan]

@rainbyte
For now, On desktop you need to set
"replaceCodeSettings": {
{ "name :"window.zoomLevel",
"value":2
}
}
and for notebook , same way

[rainbyte]

Thanks @shanalikhan, that's what I'm doing now, it just doesn't feel right.

I would prefer to ignore the setting globally, without config per machine, if it is possible.

[fredrikaverpil]

@borekb @shanalikhan if I read this right, you want any replacement code to be removed from the settings.json in the gist.

This would be nice, I agree, but please do not remove comments in settings.json which may contain these strings. I keep all of my different machine setups in the main settings.json file as comments.

[borekb]

I wouldn't remove the value from the uploaded JSON, I would just replace it with some known, single value.

For example, say that some settings stores a timestamp. Currently, if I upload the settings every second, I'll get many revisions of my settings.json with mess like this:

Gist v1:
option.timestamp: 1488289783

Gist v2:
option.timestamp: 1488289784

Gist v3:
option.timestamp: 1488289785

The goal would be to replace the ever-changing value with a single, non changing value, e.g., 1488289783 (it doesn't really matter). Now, when I invoke Upload settings every second, I won't get new versions of settings.json in my Gist.

[shanalikhan]

@borekb which setting key is changing, can you explain the real example of any extension of anything that cause change in values in settings.json again and again

[borekb]

@shanalikhan for me, it's window.zoomLevel. I change it frequently.

[shanalikhan]

I have released v2.7 adding this feature.
Let me know if there is any error, i will fix and release new version with documentation.
Or if its working fine 😄

[borekb]

Excellent! How does it work? I see a new ignoreUploadSettings key in syncLocalSettings.json, do I put some fixed value there and some regex will replace it in the uploaded settings.json? Thanks.

[shanalikhan]

For now , some fixed value !

like replaceCodeSettings

Oh i have posted the ignoreUploadSettings in read me also
Check that

[borekb]

I tried this in syncLocalSettings.json:

"ignoreUploadSettings": {
    "window.zoomLevel": 3
},
"replaceCodeSettings": {
    "window.zoomLevel": 2
},

This should mean, "when uploading to Gist, put 3 as the zoom level; when downloading, replace the value from Gist to 2". But I end up in 3 in the zoom property after download which feels incorrect. Also, it moved the zoomLevel it in my settings.json from top to bottom, not sure why.

[borekb]

Oh I see, ignoreUploadSettings removes the value from settings.json sent to Gist and applies the value when downloaded. Not sure how that fits with replaceCodeSettings; it seems that there is some overlap between the two.

[shanalikhan]

for your case, u only need one thing
Remove the replaceCodeSettings child.

"ignoreUploadSettings": {
    "window.zoomLevel": 3
}

Any value in window.zoomLevel will replace 3 and then remove from settings, upload and then get the value from there and put in settings.

There was no other way to do that.

I'm closing this issue, let me know if there is any problem

[borekb]

I either still don't understand how this is supposed to work, or it doesn't work correctly.

I have this in my syncLocalSettings.json:

"ignoreUploadSettings":{"window.zoomLevel":1}

and this in my settings.json:

"window.zoomLevel": 1

Now I close VSCode. The next time it starts, it downloads settings from Gist due to this configuration:

"sync.autoDownload": true,
"sync.autoUpload": false,

After this, I am left with a broken window zoom as it is completely missing from settings.json.

What removed it from there? I guess it's still not clear to me when exactly are ignoreUploadSettings applied; seems like not only during the upload because I was not uploading and it still removed window.zoomLevel from settings.json.

[swarnendubiswas]

@shanalikhan Did you hear back from upstream about the bug? I experience the same issue, I specify the list of keys to exclude, but they keep appearing in the gist.

[evenfrost]

Same for me. I've set

  "ignoreUploadSettings": ["editor.fontSize"],

in syncLocalSettings.json but it still appears in the gist.

[evenfrost]

SO, what's current workflow to keep some settings local? E.g. I have "editor.fontSize": 14 in synced settings which are uploaded to a gist, but want to set "editor.fontSize": 15 on different machine. What should I set then?
I've tried to use different combinations of "replaceCodeSettings" and "ignoreUploadSettings" fields in my "syncLocalSettings.json", but nothing seems to work, font is still shows as 14px.

[syepes]

+1

[robertpeteuil]

@swarnendubiswas @evenfrost @syepes - I dont have much good news to share. I've ran into a similar issue and have spent a while research it to no avail.

I can tell you that the upstream issues he mentioned about have been closed. One was flagged by-design and they second was auto-closed in July for "needs more information and has not had recent activity".

Also - ignoreUploadSettings has been removed, according to the commits listed above. So the only options left is replaceCodeSettings. It doesn't work correctly for my scenario, and it seems like the extension owner is focused elsewhere for the time being.

[shanalikhan]

@robertpeteuil Dont worry! 😄

I'm the only one working and maintaining.
Hard to manage Open Source, Office and Study! ( Looking forward for contributors )

I worked on this feature and after reaching toward end , found some show stopping Code API limitations so i had to revert it.

Released v2.9 today with alot of features.
I will release v3.0 with this fixed soon.

Update : I have to look when its possible to work on it :)

[robertpeteuil]

@shanalikhan Awesome, thank you.

I understand the challenge of maintaining open source, while juggling other responsibilities.

There was a specific issue I was having, which I believe is (or at least was) related to the logic of how it processes ignored local settings.

• Specifically, if an ignored setting has a value of false, it assumes that it can be removed from the local settings.
• This is an incorrect assumption as there are settings that default to True which require explicit False values.
  • In these cases, deleting the setting is the same as setting it to True

An example - I was trying to hide the Docker Explorer on 2 of machines but allow it to be shown on a 3rd. (It's displayed by default, unless there's a setting that explicitly sets it to False)

• I set it to ignore changes of the setting docker-show-explorer (made up setting name)
• on the machines where I wanted it hidden I set docker-show-explorer to False
• on the machine where I wanted it shown I set docker-show-explorer to True
• during a sync, the setting is deleted on the machines where it was set to False
  • as mentioned above, this is bad, as it's the same as setting it to True.
• I tested this by changing the values of these settings to both True and string values.
  • In these cases the sync properly kept the local values.
  • It's only the False value that causes this un-wanted behavior.

I hope I explained this properly. If not, let me know and I'll provide more details.

[spali]

Hi
Just stumbled about this.
Just my two cents about the settings replaceCodeSettings. For my and the example use case with the proxy it works in general.
But what I don't like in this way (filter/set during download settings) for example the proxy settings (even it's not confidential), it should never go outside the company, because it will never works outside the company.
So for a perfect world the upload filter (but be sure to keep the setting locally and don't override it next download) like the above would be a cleaner solution in most cases in my eyes.

With this I currently don't know any use case for replaceCodeSettings. Because you could always configure something locally and exclude it for uploading. I just need to be sure, that the download does not override the local settings I excluded form uploading.

[shanalikhan]

Guys, what're your views about #555.
Feel free to post it there compared with this feature.

I might be closing one of these issues. Functionality is the same but the way is different.
Before that, i want good discussion.

This thread also linked with #292

[borekb]

I like it. It would allow me to manage everything from settings.json (I always forget where Sync Settings keep its custom .json config file 😅).

[shanalikhan]

Duplicate of #555

[shanalikhan]

Locking this thread. Let's keep a track over there.