Undo command unavailable for changes to binder

User avatar
Jangari
Posts: 127
Joined: Mon Jul 23, 2012 5:03 am
Platform: Mac
Location: Melbourne

Tue Oct 29, 2013 11:55 pm Post

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?

Cheers,

User avatar
KB
Site Admin
Posts: 20901
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Wed Oct 30, 2013 10:59 am Post

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).

All the best,
Keith
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

User avatar
Jangari
Posts: 127
Joined: Mon Jul 23, 2012 5:03 am
Platform: Mac
Location: Melbourne

Thu Oct 31, 2013 5:42 am Post

No worries. Thanks for the clarification.

Bd
Bdillahu
Posts: 54
Joined: Wed May 25, 2011 3:36 am
Platform: Mac, Win + Linux
Location: Atlanta, GA
Contact:

Mon Dec 30, 2013 9:37 pm Post

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".

bo
bobmzed
Posts: 2
Joined: Sun Apr 27, 2014 3:36 pm
Platform: Mac

Sun Apr 27, 2014 3:42 pm Post

Hi there,

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?

The undo was disabled and there is no revert.

Hu
Hugh
Posts: 2444
Joined: Thu Mar 08, 2007 12:05 pm
Platform: Mac
Location: UK

Sun Apr 27, 2014 4:59 pm Post

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.
'Listen, some quiet night, when you've shirked your work that day. Do you hear
that distant, almost inaudible clicking sound? That's one of your
competitors, working away in the night in
Paris or London or Erie, PA.'

bo
bobmzed
Posts: 2
Joined: Sun Apr 27, 2014 3:36 pm
Platform: Mac

Sun Apr 27, 2014 6:15 pm Post

Thanks so much.

Ly
Lynm
Posts: 4
Joined: Sun Nov 02, 2014 6:05 pm
Platform: Mac

Sun Nov 02, 2014 6:20 pm Post

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.

Hu
Hugh
Posts: 2444
Joined: Thu Mar 08, 2007 12:05 pm
Platform: Mac
Location: UK

Sun Nov 02, 2014 10:43 pm Post

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...
'Listen, some quiet night, when you've shirked your work that day. Do you hear
that distant, almost inaudible clicking sound? That's one of your
competitors, working away in the night in
Paris or London or Erie, PA.'