Enhancement: Add edit mode for files generated by configx

[Ansh934]

Enhancement: Add edit mode for files generated by configx

Summary

Add an edit workflow so users can modify files that configx originally generated, without manually editing Neovim config by hand. The feature should support safe updates and prevent config conflicts when the generated files have been customized after creation.

Problem

Right now configx is effectively a one-way generator: it creates a Neovim config tree, but there is no supported way to edit or reapply changes to those files later.

This creates two issues:

• Users cannot easily revise their earlier choices without regenerating from scratch.
• Regenerating risks overwriting manual edits or introducing conflicting config between tool-managed content and user changes.

Proposed Enhancement

Add an edit mode that can:

• Re-open an existing generated config tree.
• Detect what configx previously generated.
• Let the user change only the sections that configx owns.
• Re-write files safely, preserving user edits where possible.

Conflict Prevention

We should prevent conflicting configs by separating tool-managed content from user-managed content.

Recommended approach:

• Mark generated sections clearly in each file so configx can update only those regions.
• Keep a manifest of generated files and the selections used to produce them.
• On edit/re-run, compare the current file contents to the manifest and warn if a file was manually changed outside managed sections.
• If a conflict is detected, do not overwrite silently. Show the user a diff or prompt for confirmation.
• Prefer patching known sections instead of rewriting whole files.

Possible implementation strategies:

• Section markers inside files, such as tool-owned begin/end blocks.
• Split generated config into stable tool-owned files plus user override files.
• Store a configx state file alongside generated output and regenerate from that source of truth.
• Use a merge/diff flow when editing existing output.

Acceptance Criteria

• Users can open an existing generated config and edit it with configx.
• Re-running edit mode does not overwrite unrelated manual changes without warning.
• Tool-owned sections are updated consistently and deterministically.
• The app can detect when generated files have been modified outside configx.
• The UX clearly tells the user when a conflict exists and what action is required.

Notes

This feature is especially important if configx becomes a long-lived config manager rather than a one-time generator. The safest default is to treat generated output as partially owned by the tool, not fully owned by it.

[aayank13]

LGTM

[Ansh934]

Preferred approach: create a manifest file that stores the original configuration choices and the generated metadata for each managed setting, not just per file. On edit mode, configx should load this manifest, show only the settings it owns, and allow the user to update those values safely.

If configx detects that a user has manually changed a managed setting since it was generated, it should warn the user before applying the edit. In that case, the tool should not overwrite the value silently; it should require explicit confirmation before updating the conflicting setting.

This keeps configx deterministic, avoids accidental loss of user changes, and makes it clear which parts of the config are tool-owned versus user-owned at the setting level.