New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
yanex opened this Issue Jan 6, 2018 · 9 comments

Comments

3 participants
@yanex
Copy link
Contributor

yanex commented Jan 6, 2018

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.

@yanex yanex added the feature label Jan 6, 2018

@ghost

This comment has been minimized.

Copy link

ghost commented Jan 6, 2018

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

This comment has been minimized.

Copy link

ghost commented Jan 6, 2018

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

This comment has been minimized.

Copy link

warpkanal commented Jan 7, 2018

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

This comment has been minimized.

Copy link
Contributor Author

yanex commented Jan 7, 2018

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

This comment has been minimized.

Copy link

warpkanal commented Jan 7, 2018

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

This comment has been minimized.

Copy link
Contributor Author

yanex commented Jan 7, 2018

@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

This comment has been minimized.

Copy link

ghost commented Jan 7, 2018

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

This comment has been minimized.

Copy link
Contributor Author

yanex commented Jan 7, 2018

@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

This comment has been minimized.

Copy link

gildor commented Jul 30, 2018

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

@yanex yanex added this to the 0.6.1 milestone Jan 3, 2019

@yanex yanex added the fixed label Jan 27, 2019

@yanex yanex closed this Jan 27, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment