It sounds like you are referring to how some applications work with individual documents you open, like Scapple or .txt filesāi.e. simple formats that can be loaded entirely into memory at once and operated on purely āoff diskā until you choose to save the file (or not). There really isnāt much of a comparison between formats like that and a program like Scrivener. I just tried three other programs that work more like Scrivener, where one loads a container that houses potentially thousands of files and only loads into memory the ones you work on within that session, and out of all of those, none of them had some kind of overarching āAre you sure you want to quit without saving changes?ā when closing the container/database/etc.
It is (a) not a feasible mechanism for this kind of software, and (b) there is no infrastructure for it on the Mac even if it were. So we arenāt āoverridingā anything, and we arenāt doing anything terribly out of the ordinary for this kind of software.
I will agree with you that locking would be nice in Scrivener, and it isnāt uncommon to find locking in database style programsābut it is a little more complicated than you seem to be thinking it would be, and of the one example I tried that is very much like Scrivener in this regard (Ulysses), it works exactly the same, with no locking.
Consider for example if you have one locked paragraph in a 100-item Scrivenings session (or a section of sheets in Ulysses). What happens then? Is there an immutable chunk of text in the middle of your file? If you change the font wholesale on that 100-item chunk of text, are patches of it ignored if locked? That could result in some embarrassing mistakes down the line if you thought the font was changed and never noticed until a reader wondered why there was suddenly a Courier paragraph in the middle of the book. Or what if you loaded that chunk of text with the intention of bulk search and replacing a character name? These are not challenges that a more typical database style program has to faceāwhere one doesnāt consider chunks of text in the outline to be smaller ingredients in a longer span of text. Itās probably not an impossible problem to work around, surely, but I have a difficult time visualising an elegant approach to these problems.
Theory aside, hereās what I do to have peace of mind: switch on the Take snapshots of changed text documents on manual save setting, in the General: Saving preference pane. Using manual save is already a bit of a habit for me because I also make use of the Back up with each manual save setting in the Backup preference pane. When Iāve done a chunk of work and Iām happy with the state of everything Iāve worked on in that session, I hit āS and in doing so I get every single file Iāve touched backed up individually with snapshots, as well as the project structure and content as a whole.
There is nothing convoluted about that to my mindāit is in fact precisely the same sort of mechanical action/reaction you get from a single-document based application where when you save a file thatās your last anchor point set. I donāt have to think about these snapshots, I never do, and when I need them they are there.
The only downside to that approach really isnāt much of one in Scrivener 3. In the past it meant a proliferation of hard to clear out snapshots. The snapshots still proliferate of courseāthat is what we want after allāitās the clearing of them that is now easier: the Documents āø Snapshots āø Snapshots Manager feature makes it a simple affair to purge these old automatic snapshots across large groups of documents at once.
Users manage to accidentally turn on script mode and revision mode all of the time, so I have no doubt that weāll get plenty of users who would accidentally lock their documents and panic.
