I just deleted a page I was working on for days and it’s gone - never to be found. I selected a document in the binder and didn’t click properly in the text window - so my cursor was not active in the text window. I went to delete some previously selected text and the document was deleted instead. I should have recognized that the cursor was not active in the text window as the selected text was gray, not yellow. Ok so far. Fair enough that it would delete the document. But there is no undo for this! My error cost me days of work! This is very poor functionality!
I think this is a terrific product. It has many great features that I enjoy. And this was my mistake. I admit.But there should be an undo function specifically for people who make an error as I did.
Ok, perhaps I am over reacting. It is painful to see this gone. But, Literature and Latte, help the poor, inattentive-to-technology-pitfalls writer and put an undo capability for undeleting a document!
I think your file will just be in the trash of your project (not your mac os). Click on the trash icon in the binder and you should be able to find it.
Wow, my face is the color of Kris Kringle’s suit. Can I delete this post? I don’t want such negative sentiment for a truly great product listed here. This is the epitome of operator knuckle headedness.
Actually this happens quite a bit. Many many a panicked post has been answered with “check the binder trash”. The panic is understandable. Don’t be embarrassed at all.
Ha, don’t worry about it, I’ve been on the receiving end of much worse. And really, this comes up a lot - so much so that the shortcut in 2.0 has been change to cmd-delete, to match the behaviour of the Finder and so that no one accidentally moves a file to the Trash folder just because the focus is in the wrong place.
Have a great Christmas,
Keith
Actually this is still a hideous issue, actually worst unintended feature ever! If you delete a file it is in the trash…very good. However, if you accidentally delete text, change the page and change back, your text is gone forever! That is, the undo in scrivener is page-specific and not application specific. This wouldn’t be so bad except for scrivener’s otherwise excellent auto-save feature which ensures that this is all overwritten and you would have to roll back to the last backup whenever that is.
I have no idea how to resolve this as it seems application wide undo is very complicated. Although I do know that this happened to a colleague of mine the first day I was showing her scrivener and it pretty much sealed the deal for her: no way will she use it or trust it. It also happened again to me recently and destroyed an abstract of 300 words - short, but a very important document.
This is simply not true. Each main text maintains its own undo stack. If you type something, switch to another document, and then switch back to the original text again, you can undo the changes you made there.
Undo doesn’t work across the board - sometimes the undo stack will have to be reset for various reasons, especially in the binder - but for the problem you describe, it should still work. And you’ll find undo an issue in any application that uses a multiple document structure, because the Cocoa frameworks link undo to views rather than the underlying data structure.
But of course, it’s always impossible to accidentally delete text in any application - Word, TextEdit, anything - and it’s always possible to get to a stage where undo won’t work in any application. But that’s why you have snapshots in Scrivener. Take a snapshot, and you can always return to that version of the text no matter what.
Perhaps your colleague and yourself are only clicking on the binder’s label of the document. You have to actually click in the document itself to undo. I use this feature regularly with no problems whatsoever.
Keith: Is it possible, perhaps in 2.1 or some future version, for Scrivener to automatically switch keyboard focus to a document that you select in the binder? Would there be any major issues created by such a change in behavior? Seems like it would solve this kind of misconception and improve the user’s experience, but I’m sure there’s a down-side.
That would mean that you wouldn’t be able to navigate the binder using the keyboard, as it would never have focus, which would drive many users (myself) up the wall. Consider Apple Mail - if you click in the side bar, it never has the focus, so the arrow keys can never be used to navigate the mail box list. Not a big deal in Mail, but in Scrivener it would be a problem.
All the best,
Keith
P.S. I should apologise to blurky as the tone of the beginning of my reply came off badly - sorry about that. I didn’t mean to say this hadn’t happened to you, only that undo does work the way you were asking for, so it must have been something else, such as can happen anywhere.
You did indeed read it right. Undo on the other hand is much trickier and will remain as it is. I’d love to improve it at some point, but it’s a maze. In Cocoa undo is associated with the view layer, meaning that as soon as the view has its content swapped, undo breaks. This is why binder undo doesn’t work very well in Scrivener, because when you select a document the content of the main editor and inspector gets swapped out. (That’s why undo in the binder does work if you have locked the editor so that the content doesn’t get swapped.) In an ideal world I’d be able say to the undo stack, “Hey, I just swapped this document, replace the sub-undo-stack associated with it with the one associated with this new document, and remember the changes made to the binder still.” But there’s no way of doing that. That’s why I created a separate undo stack for each main text, so that at least you can undo changes to the main texts even after you’ve changed documents. But I can do that because in Cocoa you can tell a text view to use a different undo manager - you can’t do that for an outline view such as the binder. I could in theory maintain a different undo stack for the binder, but this could be confusing too - when the user hit undo, he or she wouldn’t know which undo stack was going to be affected. So they might hit undo having made a change in the inspector that has has no undo associated with it, thus calling undo on something they did in the binder ages before, and not notice the change that has been made.
Ahh…each window has its own undo stack, and I did experience the behavior described.
With windows flying everywhere, how is it that you can properly cue the user to understand the each-window-undo-stack idea? Doesn’t seem easy, if at all possible.
In any case, I’m sure there are more important things to worry about with version 2.0. Best of luck.
P.s. is there a list for beta testers? I’m willing to take the risk with some of my work.
And really, this comes up a lot - so much so that the shortcut in 2.0 has been change to cmd-delete, to match the behaviour of the Finder and so that no one accidentally moves a file to the Trash folder just because the focus is in the wrong place.