Preferences: Migrate from JSON to some more user-friendly config format

[yanex]

Pros:

1. JSON is widely used. A lot of people are already familiar with it.
2. There are a lot of good parsers for JSON.
3. JSON highlighting is supported by all modern text editors.

Cons:

1. JSON is too strict for user-modified configuration files.
2. Almost all JSON parsers do not support comments.
3. JSON generators does not preserve formatting.

Goal: support editing conf.json using GlobalContext.set(). This will allow changing configuration values (for example, themes) directly from Marta.

[ghost]

Not a huge issue IMO
Once you know json it‘s usable.
Crystal-Lang had pretty much the same issue with their yaml dependency management file and have not solved it yet either

[ghost]

what micro does they just have no comments and sort the json data alphabetically because plugins insert their settings into the same json
It's surprisingly not that bad.

Maybe marta could auto format the user settings (assuming the default settings are automatically generated) and eliminate any comments in the user config.
Since the settings appear in a split view now, one could lookup the comments in the default config file as needed.
This would also allow new settings to be added to the user file as they appear.

I'd actually appreciate my user config to 100% mirror the default options (not the settings true/false, but the options "option":"setting")
As it's now, I have my user settings mixed up and the order does not match up with the default config which makes it harder to compare which settings I've already configured and which comments in the default file go along with each option in the user file...

[warpkanal]

I personally favor json + comments (and I think it's a huge mistake to not have included comments in the json standard for the reason you mentioned: most parsers don't like it, but that's a long story...).
I don't like YAML and simple key=value prop files are probably too limited.

My take: editing json files is not too much user friendly but definitely OK for a power-tool like marta.
A full configuration UI is for sure more user-friendly but quite some effort (although it could be done in a generic way, generating it out of the default configuration...)

[yanex]

I personally prefer HOCON. It's similar (and backwards-compatible) with JSON, but much more user-friendly. I think, though, that it would be better to support only a subset of HOCON, omitting features like concatenations, path expressions or substitutions.

YAML – no way :)

[warpkanal]

Thanks for that HOCON hint, never heard about it, but definitely sounds like everything I ever wished from a config approach (i.e. too often implemented overriding by java system properties on my own 😄 )
By "omitting features" I guess you mean that you need to write your own parser for Swift?
So yes, why not, go for it !

[yanex]

@warpkanal Yes, it will be the new implementation because:

1. You're right, there's no decent HOCON implementation for Swift/ObjC. There are for C/C++, though.
2. Existing implementations (also for HOCON alternatives such as jsonic) don't care about whitespaces and comments. I need them to be able to modify configuration, preserving the existing formatting. I personally would be very angry if some tool break my config for no reason so I don't want Marta to do this :)

But I agree, this is not a high-priority task (at least for now), and it will take quite a lot of time to be done properly.

[ghost]

To me this sounds more like don't roll your own crypto also applies here in a different environment/ NIH.

If you write your own parser and generator you might probably as well create some UI check-boxes and make it entirely user friendly/ non geeky. I mean who want's to learn a new format just to config something? (and if one does not learn it one could just as well stay with good old json)

[yanex]

@monouser7dig No, it's very unlikely Marta will have a complete Preferences dialog. However, there are some particular preferences that I might be want to configure using the UI.

The good example I already said about is a theme changer. An another one is a key binding mapper. Imagine you can add bindings just from the Action panel without even knowing the particular action id.

I spent some time reading about different configuration formats in the past several months, and I found nothing really good. JSON is so-so, the main problem is that it's too strict, and I always feel I want to have something similar, but with a simpler syntax.

I also don't think that learning new configuration format will take much time if the format itself is good enough (and close to JSON).

[gildor]

+1 for HOCON. Sound like the best option for human readable and writable format. Hope some Swift parser will be available at some point