I’ve replicated this on Scrivener 1.11 on Tiger, and on Scrivener 1.5 on Leopard:
In Edit Scrivenings, the Undo memory gets permanently lost switching between Full Screen view and Binder view, and visa versa. Switch back to the original view in which the text was edited and it remains lost. This happens regardless of whether the Edit Scrivenings are Locked or not. However, Undo seems to work fine switching back and forth between the two views with individual documents.
I’ve replicate this a number of times. I’ve lost small snippets of text, but it has the potential to be more serious.
Undo has to be reset at various points. One instance is when a text is edited in Edit Scrivenings mode (because E.S. has to use a different undo manager). Undo is a very tricky business when working across multiple files as Scrivener does, so unfortunately there is no way around it but to reset the undo stack when it gets to a point where it may be out of sync with the actual data.
All the best,
Keith
Couldn’t the undo history be saved somewhere BEFORE reset, say in a hidden file (even offboard Scrivener), perhaps just a history of cut text, so at the least it could be retrieved manually? I guess this would have to happen just before switching in and out of Edit Scrivenings.
I’m sure you can appreciate the potential for lost work here. As I say, my losses have been small, but I could imagine much worse.
I searched the FAQ and didn’t see a warning about this. Unless I missed it perhaps one should go there.
Thanks.
PS. I spend 99% of my time in Edit Scrivenings, switching back and forth between Binder and Full Screen view. I’m sure there are others.
You will find that many programs that allow you to switch between files in one view have no undo at all after you switch files. So I’m afraid no, there is no way of doing this. One of the pains of undo in Cocoa is that it is associated with the view rather than with the underlying data. In Scrivener, each text has its own undo stack, but this has to be passed to the text view to handle. In Edit Scrivenings, there is no way for all of these undo stacks to be used - a separate one has to be used for the combined text. And if you make edits, there is no way of telling the undo stack for the edited text in E.S. about that change - there simply no way of doing this with the Cocoa undo architecture. So at that point, an edit has been made that in the combined text that the individual undo stack does not know about about - it thus has to be reset otherwise it will be out of sync. Undo stacks in Cocoa are designed to be linear; but Scrivener is not linear.
This is indeed unfortunate, because I suspect Scrivener users switch views more often than in many other programs.
Not to quibble… well, OK, to quibble a bit, couldn’t cut text be saved to some file. Would this be technically feasible, if perhaps less elegant than you would like? The risk of lost work in not inconsequential for writers, even if Cocoa is responsible for that risk.
It’s just not really feasible, no. I have to say that I have never inadvertently lost text in this manner though, and I use Scrivener a lot myself. If you feel it is something you are likely to do, I recommend getting in the habit of hitting cmd-5 to make a snapshot of your document - that way you can always return to it in an earlier state if you need to.
When it comes to undo, I can only work with what the Cocoa frameworks have to offer. Different programs handle it differently but all have limitations. For instance, whereas Scrivener assigns a different undo stack to each text (which then has to be reset), some programs use one undo stack and somehow manage to assign the undo out of the view hierarchy. The problem with that approach, though, is that you can end up inadvertently undoing changes you have made to documents you can’t even see on screen.
Well, using snapshot in this way raises another question I have… and that’s about snapshot itself.
I tend to save backup copies of files and folders, entire chapters often, very, very frequently. It just gives me a warm, comfortable feeling every time I start a new revision.
I have not used snapshot because I have not wanted to bloat my project with all these backups. Consequently, I have an entirely separate backup project for this purpose. This is cumbersome, since every time I want to save a backup, I have to launch the project and then drag over the files and folders, then close the project. The advantage of this system, though, is that when I want to search all my backup “snapshots” I have the search and organizational power that is included within the Scrivener program (much better tools than exists in the snapshot window).
Currently, my writing project runs 15.6 MB, while my backup project runs 44.6 MB. If all of that was contained in my writing project it would add to the burden of backing up my writing project at the end of each session (compressing it), and then backing this up to other media and over the Internet to an offsite location.
You probably know where this is going… any chance that we could have the option of saving our snapshots to an off-board “snapshot” project?
And then… I just realized… if we could have an automatic snapshot function every time we switched views - hey, problem number one would be solved at the same time!