Summary
Add a full live-save / autosave / recovery model for file-backed editing.
This is intentionally a deferred epic. The goal is not just “save more often”, but to make file-backed editing feel safe and predictable in the same class as mature editors.
Rationale
Research notes from other editors suggest the feature only works well when several layers land together:
- Obsidian appears to treat disk state as close to live editor state, which keeps file-based workflows coherent but also increases conflict pressure with cloud/sync tools.
- VS Code couples autosave with backup/hot-exit infrastructure, save reasons, and strong working-copy semantics.
- Zettlr uses debounced autosave plus watcher-based remote change handling and explicit conflict prompts.
- Logseq separates periodic persistence from UI editing and only flushes when changed and idle.
The lesson is that autosave is not one toggle. It is a persistence model.
Principles
- In-memory editor state stays authoritative.
- Disk writes are debounced and revisioned.
- Explicit flush points exist beyond the idle timer.
- External file changes must never silently overwrite dirty in-memory state.
- Crash recovery is separate from normal save-to-disk.
- The UX must expose save/recovery/conflict state clearly.
Deferred subissues
Non-goals for the first pass
- Perfect three-way merge UX
- Collaborative editing semantics
- Sync-provider-specific behavior
Why this is deferred
This cuts across frontend UX, backend persistence, file watching, shutdown behavior, and recovery. Shipping only one thin slice would likely create data-loss or trust issues.
Summary
Add a full live-save / autosave / recovery model for file-backed editing.
This is intentionally a deferred epic. The goal is not just “save more often”, but to make file-backed editing feel safe and predictable in the same class as mature editors.
Rationale
Research notes from other editors suggest the feature only works well when several layers land together:
The lesson is that autosave is not one toggle. It is a persistence model.
Principles
Deferred subissues
Non-goals for the first pass
Why this is deferred
This cuts across frontend UX, backend persistence, file watching, shutdown behavior, and recovery. Shipping only one thin slice would likely create data-loss or trust issues.