Open mcandre opened 4 years ago
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.
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.
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).
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.
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 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: https://github.com/zyedidia/micro/issues/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