Skip to content

feat: interactive config set to edit and persist preferences #99

Description

@davidtaing

Problem

The config command added in #92 is read-only — treetop config show prints the
effective preferences and where they come from, but there is no way to change
them from the CLI. Today the config file (#90) is entirely hand-edited: a user
has to know the path ($XDG_CONFIG_HOME/treetop/config.json or
~/.config/treetop/config.json), the JSON schema, and the key names to set a
preference. No production code writes the file yet.

Proposed

Add an interactive subcommand — e.g. treetop config set — that walks the user
through the persisted keys and writes the result to the config file. It
complements the existing read-only config show (set writes, show reads).

The keys are the ones defaultConfig() / config show already cover
(config.go):

  • watch, pr, checks, notify, projects, color (bool)
  • interval (int)

Flow sketch: prompt through each key (current effective value shown as the
default, so Enter keeps it), then persist. Since this is the first code path
that writes the config, it needs to:

  • create the config dir if missing (MkdirAll), resolving the path via the
    existing configPath(),
  • marshal the config struct to JSON and write atomically (temp file +
    rename) so a crash mid-write can't corrupt an existing config,
  • only persist keys the user actually set, preserving the nil-vs-zero-value
    distinction the config struct relies on (don't splat all 7 keys with
    defaults).

Design forks (worth deciding before building)

  • Interaction style — a full bubbletea TUI (consistent with watch mode), or
    a plain line-prompt walkthrough (smaller, no TUI deps in this path)?
  • Surface — one guided walkthrough of all keys, or also a non-interactive
    config set <key> <value> for scripting/single edits?
  • Namingconfig set, config edit, or config init? (edit sometimes
    implies opening $EDITOR on the raw file, which is a different, cheaper
    feature.)
  • Merge behaviour — load the existing file and edit on top of it, vs. start
    from effective defaults and overwrite.

Scope

The write side of the config the config show command already reads. Follow-up
to #90 (persist) and #92 (read-only inspect).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesthitlNeeds a human (decision/design/review)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions