Is there a reason that the ‘undo’ command becomes unavailable whenever things are moved around the binder?
I often find myself in the position of having accidentally done something like split a document or add a new document due to my rather overzealous use of keyboard shortcuts (including several custom shortcuts I’ve created) to do just about everything, which then means my occasionally sluggish fingers get it wrong and I hit ‘split’ instead of ‘insert image’ or something.
Ordinarily, one would hit cmd-Z and undo it, but it appears that undo is not available for some changes that affect the binder. So in the case of an errant split, I have to change the focus to the original document, the pick up the split document and drop it into the editor window, then move the split document to the trash. After doing this fairly frequently, I have ended up with a rather inflated trash (which I suppose I could empty). The point is it means for several more keystrokes – and mouse movements – than should be necessary.
Adding a new binder document cannot be undone, nor can a split, but a movement of existing binder documents it appears can be, unless that movement results in the different embedding of documents. As a test, I moved one document to being before another one, and undo was available. I moved it inside another one, and it was not.
Is there a limitation imposed by the way the documents that form the binder are organised in the filesystem that means undo is not possible for some actions? And if not, is there something else that could be preventing it?
Yes, it’s down to the limitations of Apple’s undo stacks. For some reason, Apple decided to implement undo at the view level rather than the model level for many areas. Because there are so many different views that can show data, this means that when the content of a view is swapped out, the view now remembers the undo stack for data that is no longer present, so if the undo stack doesn’t get cleared, it will throw errors as it will try to operate on something no longer there. Scrivener gets around this to an extent for the editor area by associating a different undo stack with text and supplying the correct undo stack to the text editor when requested, but this isn’t a feature of other view types. There is no way to associate a unique undo stack with the binder, for instance (and even if there was, that could cause problems for the outliner and corkboard). You’ll find similar undo restrictions with similar programs (Ulysses, for instance, also lacks undo in most situations when you drag sheets around).
I understand the technical limitations, but have to put in my “sure wish we could do something about it” request… I’ve botched up a book that I had published with a glitchy mouse/drag-drop and suddenly moving one item in the binder had me mistakenly moving a chunk of my book around. When you have various “pieces” in each Chapter, having them suddenly rearranged and no way to recover was a pain.
Wound up having to delve into backups, etc.
This isn’t an issue with an app that doesn’t autosave, but when Scrivener autosaves every few seconds, you don’t have time to even manually “heck, I’ll just close without saving and go back to where I started”.
I’d like to confirm something. I hit the delete icon in the toolbar rather than the add button. This was just a careless mistake. Because of my general inattentiveness in everything I do there is no way I’ll avoid this in the future. Is the conclusion of this discussion that there is no way to undo that mistake?
If you delete a document in error, you will find it by double-clicking Scrivener’s Trash which is at the very foot of the Binder; you can then right-click on the file, click on ‘Move to’ and restore it to your Draft or Research folder.
Scrivener’s Trash is in effect a safety net for precisely the situation you describe.
Actually, I was unable to find my deletion in the trash. I deleted a section by mistake and it is just GONE! Not in the trash, not in my computer back up…at least not enough. The tutorial said I couldn’t delete permanently by mistake. Well, it seems that I have done just that.
Any suggestions?
Thanks.
This is a case where Cmd-z is the way to go (because what you describe isn’t actually a binder issue - no document has been deleted in its entirety). So long as you realise in time that you’ve made a mistake…