Consider storing user-specific settings/overrides in /bramble-config.json

[humphd]

We're starting to grow our list of extensions, settings, preferences, etc. I wonder if we should consider storing these for the user locally in their filesystem at /bramble-config.json or something, and have Bramble read this file and adjust things when it boots. You could use this to update various things for yourself, and have it persist across projects.

I'm not suggesting we try to sync this across devices, but just being able to have it at all would be nice. Thoughts? A lot of editors work this way now (i.e., file based prefs).

cc @flukeout, @gideonthomas, @Pomax

[Pomax]

I kind of want to see this list as a user-accessible menu somewhere, probably with the kind of local backing you talk about. Not letting people turn on/off extensions that are actually trivially loaded with a runtime argument seems silly: that's power we can give to the user.

[humphd]

This is a great thing for @flukeout to solve for us, since our pattern of adding "toggle" switches to the gear icon in Thimble is getting a bit...long in the tooth.

[gideonthomas]

+1 to @Pomax's suggestion and yeah, it would be really nice to give the users the ability to control what they're seeing.

Any reason you suggest storing it as a file vs. localStorage?

[humphd]

"give the user's control" is why I suggested a file, since we have implemented a file editor :)

[Pomax]

I have mixed feelings about files, given how little love I have for sublime's way of doing configs (and how easy it is to delete them), but I'll be happy to shelve that until @flukeout works his magic =)

[flukeout]

I think the user-facing facing part should definitely be some kind of custom UI. We can certainly use hidden files or something like that to keep track of the settings, but I wouldn't want to expose the settings as a file (at least not as by default).

[Pomax]

the risk with any hidden file is the user making a file with the same name, so I don't know if "hiding" is a good solution. Could we show a settings file as part of the file tree in a way that users can edit it, but won't normally be motivated to do so?

[humphd]

If we're willing to do a proper UI for this, then I would say having it be a file is not important (i.e., backend the UI with localStorage is fine). I also thought that having it be a file would allow us to expose this without investing a ton of resources into designing/implementing/maintaining. I think that doing custom settings is just that, custom; and not a beginner task. However, I am happy for us to do what works.

I'd suggest we close this if we don't want a file. @flukeout, you decide.