Skip to content

Keep only non-default values in the config file - #62

Merged
thesiti92 merged 6 commits into
feat/summary-providersfrom
feat/sparse-config
Oct 1, 2026
Merged

thesiti92 merged 6 commits into
feat/summary-providersfrom
feat/sparse-config

Conversation

@thesiti92

@thesiti92 thesiti92 commented Sep 30, 2026 •

Copy link
Copy Markdown
Contributor

Stacked on #60.

Why. config set wrote every resolved default into ~/.config/diffr/config.toml on the first edit (3506fb2, "Materialize full configuration on edit"). Files therefore kept a frozen copy of the defaults of their time. Later default changes, such as #60's new summary prompt or a newly bundled plugin in order, never reached them. This reverses that decision.

What changes

  • Sparse writes. Each config set drops every key whose removal leaves the resolved configuration unchanged, then every table left without values.
    • version stays.
    • A custom plugins.order stays, because removing it would change membership. An order equal to the default goes.
    • Anything with a comment on it is kept, and so is its header.
  • Old default prompts. When a file is read, the two earlier default prompts at plugins.bundled.summarize.system_prompt are treated as unset, so existing files pick up the current prompt. Temporary: remove after 2026-12-31.
  • One module. Both passes live in src/config/prune.rs and share one path-based remove.
  • Editable prompt. The summary prompt shows up in settings screens, and its description links to its default in plugin.toml. A test keeps the link's line numbers accurate.

Verified

  • cargo test, cargo xtask test-plugins and the TUI's diffr tests all pass.
  • Exhaustive: every setting the schema declares (31) is dropped when set to its default and kept otherwise.
  • Generated files: 400 seeded files mixing defaults, other values, comments, explicit headers and old default prompts must keep their meaning, prune idempotently, keep every comment, leave nothing removable and not depend on key order. Breaking pruning three ways (ignoring comments, skipping the table pass, removing without checking meaning) fails a different one of these checks each time.
  • Found by these tests: instances set to its default resolved differently from leaving it unset, so it was never pruned. Resolution now fills it in for parallel plugins, the same way it fills in enabled.
  • Real-world check: a copy of a real materialized config went from 53 lines to 9 after one config set. It resolves to the same configuration except the prompt, which is now the current default.

Trade-off. A value set to exactly today's default is no longer pinned against future default changes.

config set used to write every resolved default on the first edit (3506fb2), so files kept a frozen copy of the defaults of their time and later default changes, such as a new default prompt or a new bundled plugin, never reached them. Now each write drops every key whose removal leaves the resolved configuration unchanged, and reads treat the old default prompts as unset until 2026-12-31. Both live in config/prune.rs.
A note in the file marks intent, so a commented key or table is never pruned or hidden. Tables that only held pruned tables now go too, and pruning stops if the file does not resolve.
Every setting the schema declares is dropped at its default and kept otherwise. 400 seeded files of random settings, comments, headers and old default prompts must keep their meaning, prune idempotently, keep every comment, leave nothing removable and not depend on key order. This found that instances resolved differently when set to its default, so resolution now fills it in like enabled.
Serial plugins do not offer the setting, so config show no longer lists it for them.
@thesiti92
thesiti92 merged commit 12ad54c into main Oct 1, 2026
46 checks passed
@thesiti92 thesiti92 mentioned this pull request Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants