Skip to content
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

Deprecate JSON configuration in favor of YAML #1717

Open
mcandre opened this issue Jun 11, 2020 · 11 comments
Open

Deprecate JSON configuration in favor of YAML #1717

mcandre opened this issue Jun 11, 2020 · 11 comments

Comments

@mcandre
Copy link

mcandre commented Jun 11, 2020

  • YAML allows comments.
  • YAML is backwards-compatible with JSON.
  • YAML doesn't require as much boilerplate.
  • YAML has better semantics for handling multiple documents within a single stream.
  • YAML ain't markup language!
@joshuarli
Copy link
Contributor

I guess the main tradeoff here is pulling in gopkg.in/yaml.v2 since the stdlib doesn't have it, but comments in my micro configuration file is a very welcome feature. I don't actually need this now, but back in the past when I was adding some strange keybindings with escape sequences, the ability to comment would have been nice.

@joshuarli
Copy link
Contributor

Oh, never mind, it seems it's already pulled in and used in other places. +1 to this then. I can take a stab at this if people want it.

@joshuarli
Copy link
Contributor

Dupe: #1186

@zyedidia
Copy link
Owner

zyedidia commented Jun 30, 2020

If yaml is indeed backwards compatible then this probably is probably fine. I should note that the json is actually json5 (https://json5.org/) which allows comments with // (though I think the comments will be deleted whenever micro writes to the settings file).

@beoran
Copy link

beoran commented Nov 9, 2020

Or why not get rid of both JSON and YAML, and use Lua for everything, including configuration?
Getting rid of the JSON and YAML parsers should make Micro quite a bit lighter.

@zyedidia
Copy link
Owner

I think having one of JSON/YAML for configuration is preferable to purely using Lua because one nice aspect of the configuration system is that micro automatically edits your permanent settings when you change things in the editor, and this wouldn't really be possible with Lua.

@lslvr
Copy link

lslvr commented Nov 10, 2020

Does it make sense that any of JSON/YAML could be used in the theme files also?

@beoran
Copy link

beoran commented Nov 10, 2020

Why would Lua not be possible as a configuration file? Lua was designed in the 1990ies long before JSON or YAML existed as an extension of Sol, a configuration file language. (https://en.wikipedia.org/wiki/Lua_(programming_language)#History) A Lua table which is written out in a file is a perfect configuration file.

PIL mentions this an an important use case of Lua: https://www.lua.org/pil/25.html.

Many programs use lua not only for scripting but also for settings, here just the first 3 I could find:

@zyedidia
Copy link
Owner

Yes in theory it would be possible to use Lua as the configuration language. The problem is that the Lua engine micro uses doesn't expose the Lua parse tree for generation/modification, so automatically generating the Lua configuration code based on the in-memory configuration could prove difficult. The table approach used by lotac (thanks for the links!) seems like the most realistic for micro and probably could be implemented. I don't think this is a big priority right now, but definitely something to keep in mind for the next major version.

@yozachar
Copy link

yozachar commented Jul 4, 2024

Hi, 4 years later, I'd like to chip in for TOML based configuration. (Both Python & Rust community seem to have adopted it). TOML isn't perfect, but hey, it has become so much better. json5 has not seen activity for over two years. Go libraries like https://github.com/BurntSushi/toml/ and https://github.com/pelletier/go-toml/ can really help.

linked: #1186

Or use something much more powerful like: https://github.com/spf13/viper

@mcandre
Copy link
Author

mcandre commented Aug 27, 2024

yeah, either toml or yaml would be a step up compared to the awkward json format

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants