Dynamically update config via cli

[nikitabobko]

Very under thought synopsis:

aerospace config-write --set-scalar <config-path> <value>
aerospace config-write --clear-composite <config-path> # clear array or dict. Not allowed for namespace
aerospace config-write --add <config-path> <key-or-index> <value>
aerospace config-write --remove <config-path> <key-or-index>
aerospace config-write --reset-to-fallback <config-path>
aerospace config-write --reload <config-path>

# <key-or-index> is string for dicts, and index for arrays. 
# <config-path> is dot-qualified config path
# `aerospace reload-config` becomes effectively equivalent to `aerospace config-write --reload .`

# Combined in one request

# no-flickering
aerospace config-write \
  --set-scalar gaps.outer.top 20 \
  --set-scalar gaps.outer.bottom 20

aerospace config-write
  --remove mode.main.binding \
  --add mode.main.binding 'alt-1' 'workspace 1'

Mental model

Config is represented as recursive DTO (Something similar to Json.swift that we have in the sources right now), but every nested dictionary node should have an associated kind property with possible values (string|int|bool|dict|array|namespace).

enum ConfigNode {
  // composite
  case array([ConfigNode])
  case dict([String: ConfigNode])

  // dot-qualified config path
  case namespace([String: ConfigNode])

  // scalar
  case bool(Bool)
  case int(Int)
  case string(String)
}

The conceptual thing here is the difference between dict and namespace. dict is arbitrary length dict. namespace represents dot-qualifed config path.

$ aerospace config --get . --kind
namespace

$ aerospace config --get mode.main.binding --kind
dict

$ aerospace config-write --add mode.main.binding alt-1 'workspace 1'

$ aerospace config-write --add . alt-1 'hehe'
Config parse error

alt-1: Unknown top-level key

TODO

• The first step is a maintenance step. We should minimize dependency on TOMLKit. The whole config validation is built on top of classes from TOMLKit. We should rewrite it to: run TOMLKit first, convert its data structures to ConfigNode

Open questions

• What to do with callbacks? I don't like the idea of modifying the config-configured callbacks. For one, the callbacks can check for different conditions inside of them anyway. For another, socket-exposed callbacks serve quite a similar purpose Expose AeroSpace callbacks via socket protocol #1514
• Rename aerospace config to aerospace config-read?
• Is it possible for <value> to be a composite value?
• I don't like 3 positional args after a flag --add <config-path> <key-or-index> <value>

Use cases

• Dynamically update config via cli #628
• Combined with Expose AeroSpace callbacks via socket protocol #1514 + keyboard/mouse-event callbacks, it becomes possible to implement third-party configuration in whatever scripting language users prefer it outside AeroSpace (e.g. Lua Feature Request: Embedded script language #622)

Discussions

• Dynamically update config via cli #628

[nikitabobko]

Thinking out loud. A useful property would be to submit "additive" pieces of toml config to config-write command somehow:

$ cat <<EOF > aerospace eval-config -
start-at-login = true
EOF

Open question: cli synopsis