Session restore
Quit with windows open and they come back on the next launch: same files, same open modes, same scroll positions (when the file hasn't changed underneath). Bookmarks and markers restore with them.
Crash recovery
Every 30 seconds, documents with unsaved edits write a recovery journal: a compact sidecar describing the pending edits, never touching your original file. After a crash, the next launch offers to replay those edits before anything else opens (Restore unsaved changes?, with Restore and Discard). When the file changed on disk after the edits were recorded, the question says so and Discard is the default, with Restore Anyway beside it. A clean save or close discards the journal. If the file a journal belongs to has moved, the launch offers Locate…, Discard, or Decide Later; nothing is deleted on its own.
A replay checks the bytes around each edit before it applies it, and tells you when it could not finish:
- Some recovered edits couldn't be restored: the file no longer matches where some edits would apply, so those were skipped and the rest replayed. Nothing has been written to disk; review the document before you save.
- Recovered edits were not applied: the file opened read-only, so nothing was replayed. The recovery data is kept and offered again at the next launch; open the file writable to restore it now.
A recovered new document is still called “Untitled” and saving it always asks where; a scratch path never surfaces. And if two launches in a row fail while restoring the previous session, Caxton offers to start without restoring; the session is kept either way, so a normal quit brings it back next time.
Safe saving
- In-place saves (tried first): when every edit keeps its byte length, such as a replace with text of the same size, there are fewer than 1,000 edited regions, none larger than 8 MB, and the file is on a local volume, Caxton patches just those bytes in the file. In-place saves are protected by a patch journal. If the save is interrupted, the next launch checks the file against the journal. A file left partly written offers Restore, which rolls it back to the last fully saved content, or Keep As-Is. A file that changed since in some other way asks Previous save may have been interrupted, with Skip Restore as the default and Restore Anyway, so a newer change is not overwritten.
- Atomic saves (everything else, including any edit that adds or removes bytes, files converted from another encoding, and files on network volumes): the new version is written alongside and swapped in one filesystem operation. There is no moment where the original is half-written.
If the rollback itself cannot be written, for example because the file is read-only or the disk is failing, Caxton says so (Couldn't restore “file”), keeps the journal, and offers the rollback again at the next launch. A save that fails for any other reason, such as a full disk or a folder you cannot write to, says why (Couldn't save “file”) and leaves the window and your edits as they were. A new document needs a small backing file in Caxton's storage so its edits can be recovered; when that file cannot be created, Couldn't create a new document gives the reason.
Undo
Undo history lives with the document and is limited by memory rather than by a count. An edit of 100 MB or more keeps its bytes in a scratch file on disk instead of in memory, and when macOS runs short of memory, undo history moves to disk off the main thread, so the window keeps responding. If a saved edit's bytes cannot be read back, for example because the scratch file is gone, Undo says that it could not read the edit and changes nothing, instead of doing nothing silently. When an operation is too large to keep at all, Caxton applies it and says that the step cannot be undone. More in How Caxton Works.
External changes
Caxton watches open files. When another process rewrites a file you haven't edited, the document reloads in place; if you have unsaved edits, Caxton tells you instead of clobbering either side, and offers to compare the two versions before you choose. Keep Mine covers that one change: a later external write asks again. A file that is deleted, renamed, or unmounted is reported in every mode. When a rename or move is followed, its bookmarks and markers are copied to the new path, and later changes reach both paths until the document reloads; Save still writes the original path, and the banner says so. Appends absorb incrementally; see follow-tail.
Where Caxton keeps its data
Everything lives in the app's own folders under ~/Library: recovery journals, bookmark and marker sidecars (incident notes ride in the bookmark sidecar and are written within seconds of a change), session state (including a Timestamp Format choice), and saved filter presets. Nothing is written next to your files, and nothing leaves your machine; see the privacy policy.
Scratch files (undo spills, disk-backed indexes, working copies of converted files) live in ~/Library/Application Support/Caxton/scratch/. Caxton removes the ones a crashed copy left behind at the next launch. A second copy of Caxton running at the same time leaves the first copy's files alone.