Skip to content

fix(editor): allow saving from reading mode - #365

Merged
PathGao merged 1 commit into
sftwrdotdev:masterfrom
PathGao:fix/save-from-reading-mode
Aug 2, 2026
Merged

fix(editor): allow saving from reading mode#365
PathGao merged 1 commit into
sftwrdotdev:masterfrom
PathGao:fix/save-from-reading-mode

Conversation

@PathGao

@PathGao PathGao commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Summary

With a document that was never saved, Ctrl/Cmd+S in reading mode did nothing at all.

toggleEdit only runs its save-or-confirm flow for tabs that already have a path (if (tab.isDirty && tab.path !== '')), so an untitled buffer switches to reading mode with its content still unsaved. The keydown handler then suppressed the shortcut behind if (isEditing || isSplit) — the one action that could rescue that text was the one action the mode refused. Nothing on screen suggests the shortcut is unavailable; it just silently does nothing, and the only recovery is knowing to switch back to the editor first.

Saving is not mode-specific. The guard now asks whether there is anything to write rather than which pane happens to be visible:

  • an untitled buffer saves from any mode — documentSession.saveContent already opens the Save dialog for a pathless tab, so reading mode needs no extra plumbing;
  • a saved, unmodified document stays a no-op, so the shortcut cannot churn its mtime and wake the file watcher (which, in live mode, would reload the tab underneath the user);
  • the HOME tab is excluded by the same condition without being special-cased — it carries a sentinel path and is never dirty.

preventDefault now runs unconditionally, including for the no-op case. Previously reading mode let the shortcut fall through to the webview's own Save Page dialog.

Credit

Reported by @dayeggpi in #168. That PR also proposed two other changes, both since overtaken by other work: the "autosave + confirm before save prompts every 1.5 s" loop is fixed on master (auto-save is now disabled outright while confirmBeforeSave is on), and the menu Save entry it edited no longer exists — the macOS File submenu was removed in a later refactor. This lifts the one finding that is still live.

Validation

  • npm run check — 0 errors, 0 warnings
  • npm test — 168/168, including a new scripts/saveFromReadingMode.test.ts covering the untitled case, the clean-document no-op, unconditional preventDefault, and HOME staying unsavable

With a document that was never saved, Ctrl+S in reading mode did nothing at
all. `toggleEdit` only runs its save-or-confirm flow for tabs that already
have a path, so an untitled buffer switches to reading mode with its content
still unsaved -- and the keydown handler then suppressed the one shortcut
that could rescue it. The only way to keep that text was to switch back to
the editor first, which is not something the shortcut's silence suggests.

Saving is not mode-specific. The guard now asks whether there is anything to
write rather than which pane happens to be visible. A saved, unmodified
document stays a no-op, so the shortcut cannot churn its mtime and wake the
file watcher, and the HOME tab is excluded by the same condition without
being named. `documentSession.saveContent` already opens the Save dialog for
a pathless tab, so reading mode needs no extra plumbing.

`preventDefault` now runs unconditionally, including for the no-op case;
previously reading mode let the shortcut fall through to the webview's own
Save Page dialog.

Reported by @dayeggpi in sftwrdotdev#168.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@PathGao
PathGao merged commit 8a6126f into sftwrdotdev:master Aug 2, 2026
5 checks passed
@PathGao
PathGao deleted the fix/save-from-reading-mode branch August 2, 2026 18:18
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.

1 participant