-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Comments
I guess the main tradeoff here is pulling in |
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. |
Dupe: #1186 |
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 |
Or why not get rid of both JSON and YAML, and use Lua for everything, including configuration? |
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. |
Does it make sense that any of JSON/YAML could be used in the theme files also? |
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: |
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. |
Hi, 4 years later, I'd like to chip in for linked: #1186 Or use something much more powerful like: https://github.com/spf13/viper |
yeah, either toml or yaml would be a step up compared to the awkward json format |
The text was updated successfully, but these errors were encountered: