> What will the format be? YAML, TOML, INI?
I like TOML the most so most likely that.
The idea is to have a mechanism where you define an option once and it
becomes available as both a CLI arg and a config item, for example
defining an `h1-font` option should make the application first read from
`--h1-font` CLI arg, then fall back to `ht-font` key in the TOML stored
in, say, `$XDG_CONFIG_HOME/mcross/mcross.toml`.
I'm fine with that. One thing I'm unsure about is whether we'll still be able to remain "simple but no simpler", if every node is customizable. I suggest we allow variations in font size (and prob weight) only, except for preformatted text.
It's not worth implementing 2 different sets of configuration options IMO.
> still be able to remain "simple but no simpler", if every node is
Well my stance is that only constant values should be configurable, not
custom behavior. As long as we stick to that the config module should
add no extra complexity to the rest of the code base. For example,
`bg = 'black' if config.dark else 'white'` is custom logic, while
`bg = config.bg` is just a configurable constant. I'm aiming for the
latter, so while the number of configurable values increases, the
complexity is actually decreased.
Looks good to me. Merging it now, thanks!
However you probably shouldn't put too much effort into cosmetic
personalization for now, since I plan to implement some sort of conf
file / cli arg configuration scheme which will be more granular
(--h1-font, --h1-color, --list-size etc.)