Saving is destructive. saveHyperTranscriptToLocalStorage() (js/hyperaudio-lite-editor-storage.js) serialises the transcript into a single localStorage key — filename + ".hyperaudio" — so each save overwrites the last. It's invoked manually from the file menu (js/editor-file-menu.js). There is no autosave, no snapshot, and no way back.
Once a transcript has been saved over, the previous state is gone. That's costly here in a way it isn't in an ordinary text editor, because the transcript carries per-word timing (data-m / data-d) that can't be reconstructed by retyping — a bad Replace All, an accidental paragraph delete, or a normalize pass that mangled spans all become permanent at the next save.
Proposal
Keep a bounded version history per transcript, and give the user a way to browse and restore earlier versions.
Sketch:
- On save, write a new immutable version record rather than overwriting:
{ id, filename, savedAt, hypertranscript, summary, topics, captions, meta }.
- Keep the N most recent versions per filename, pruning oldest. N configurable, small by default.
- A "Version history" panel listing versions by timestamp, with a preview and a Restore action. Restoring writes a new version rather than rewinding destructively, so restore is itself undoable.
Design constraints worth calling out:
- Storage.
localStorage is the wrong home for this. It's ~5 MB, synchronous, and the code already has to handle QuotaExceededError with an "unable to save" alert for a single version. Version history should go in IndexedDB, which the editor already uses for media (hyperaudioMedia / media store in the same file). That's a migration, not just an addition.
- Size. Each version is the full transcript HTML. For a long transcript that's not trivial × N. Storing diffs between versions rather than full snapshots is an option, at the cost of restore complexity — probably premature; measure a realistic transcript first.
- Media is not versioned. The media blob is stored separately and is immutable, so versions can reference it rather than copying it. But an edited-media export changes the timeline; a version restored against different media is meaningless. Versions should record which media they belong to.
- Autosave. Version history is much more useful with autosave than without, since manual-save-only means the history only contains points the user already thought to keep. They're separable, but autosave is arguably the feature that makes this worth building. Worth deciding whether it's in scope here or a follow-up.
Related: #400 (undo in the editor), #394 (span normalization, a source of unwanted transcript mutation).
Saving is destructive.
saveHyperTranscriptToLocalStorage()(js/hyperaudio-lite-editor-storage.js) serialises the transcript into a singlelocalStoragekey —filename + ".hyperaudio"— so each save overwrites the last. It's invoked manually from the file menu (js/editor-file-menu.js). There is no autosave, no snapshot, and no way back.Once a transcript has been saved over, the previous state is gone. That's costly here in a way it isn't in an ordinary text editor, because the transcript carries per-word timing (
data-m/data-d) that can't be reconstructed by retyping — a bad Replace All, an accidental paragraph delete, or a normalize pass that mangled spans all become permanent at the next save.Proposal
Keep a bounded version history per transcript, and give the user a way to browse and restore earlier versions.
Sketch:
{ id, filename, savedAt, hypertranscript, summary, topics, captions, meta }.Design constraints worth calling out:
localStorageis the wrong home for this. It's ~5 MB, synchronous, and the code already has to handleQuotaExceededErrorwith an "unable to save" alert for a single version. Version history should go in IndexedDB, which the editor already uses for media (hyperaudioMedia/mediastore in the same file). That's a migration, not just an addition.Related: #400 (undo in the editor), #394 (span normalization, a source of unwanted transcript mutation).