More extensive undo functionality

It’s nice that I can undo as often as I like, but when I make a change in a chapter, switch to another chapter from the binder, then realize that last change was a mistake, it’s too late to undo the change.

I am aware of the backup feature, but by reverting the entire file, I may lose other changes I’ve made. This results in me having to mix and match the files to make sure I’ve got all the chapters right. And if I later discover that I missed something, I have to dig up the right backup again, if it’s even still there. You can see that this isn’t ideal.

Sure, there are snapshots, but I don’t want to manually take a snapshot all the time. Automatic snapshots seem better, but then at which time would it have to take the snapshot to save my work in the above example? Not to mention other examples.

What I’d like to request, is an undo history like they have in most image manipulation software. Rather than pressing ctrl+z until you’re at the right state, you can just pick a state from the list. It’d be even better if it splits up into multiple branches (for example, reverting from B to A and continuing from there would result in A branching into B and C (your current state)).

Next to that - and this seems important even with the current undo feature, - I’d like to see the undo history be saved with the file. So closing the program and reopening it has no impact on whether or not you can undo a change.

I totally agree!!!

Just the spiffiest of ideas, really, requiring a simple infinite recusion algorithm, easily enough come by and – I suspect – nothing Scrivener could not easily incorporate. The problem arises, however, when one tries, for the sake of specific access, to map the sequence of forks – finite at any particular point yet approaching infinite as one recurses to n(x) preceding forks. Perhaps you’d be better served by the “Go to > perfect revision” feature scheduled for Scrivener 11.5.


The best implementation I have seen is in Adobe Lightroom. Each photograph has its own history queue, and as you take actions they are labelled clearly in the sidebar. You can remove individual actions from the queue and it retroactively removes that action, reapplying subsequent actions. This is saved as part of the photograph’s meta-data.

However it can get away with much of that because Lightroom doesn’t actually touch the photograph, ever. Everything you do in that program applies a real-time filter. When you load a photo you’ve been working on, all of your steps are applied to it. In essence, the “history” is actually just an exposed piece of the internal real-time pixel manipulation engine. It’s a side-effect, rather than something they went out of their way to make.

It’s also relatively safe, because each action you can take in Lightroom is discrete from all other actions. There is no dependency upon adjusting the equation that establishes the curved distribution of pixel intensity within the green colour channel. That can be done all by itself, and adding or removing it will make no impact upon a function that detects sudden pixel blackness shifts and further increases the intensity of the light cliff, causing the eye to feel it has been “sharpened”. These two things can be done independently from one another—one making the lighter areas of the photograph less green, the other sharpening the edges.

But, these programs also have some pretty big limitations. There would be no need for Photoshop, otherwise. You can’t get in there and move a bunch of pixels around, or paint a clown face in the middle of a scary window. But programs that let you do that don’t have fancy editable undo history stacks any more. Photoshop has a pretty nice history palette, to be clear, but it’s mainly a UI slapped on top of a traditional linear undo stack. Much of what can seem dynamic about it is actually an illusion. For instance the ability to set a particular undo state as a painting source, and then using a brush to paint pixels back into the current state of the image, from that prior state. It’s just storing the pixels from each action you take. Photoshop does have a non-linear history option, but it’s not very fancy and can quickly get confusing if you aren’t paying attention to it while you work. (Individual action chains do not “fork” they are all stacked into the same linear sequence, so if you do “A” for a while, and undo back to Y, then do “B” for a while, you have YAB all lumped together—you better remember where A ends and B begins if Y rolls off the change list and you don’t like B.) Fact is, these programs aren’t any less “modern”, they just work under a different principle.

There is one string of bytes that are your text, and when you delete a letter that byte is physically removed from the disk, changing the position of all the bytes that came after it. Undo can only say “this byte was removed from offset x”, so long as the state of x can be derived from a strictly linear reconstruction of the data. You can’t bring that byte back in the same place, if the place is no longer where it used to be (because you added a paragraph at the top of the file somewhere in between deleting the byte and decided you wanted it back, without undoing all of the changes you made in between). All that could be done at that point is plopping the byte back into the original offset, which would almost certainly mean a stray letter in the middle of nowhere.

So that’s the problem with non-linear undo when you’re actually editing data, and the edits of that data produce incompatible states from one sequence to the next. It’s not old-fashioned, it is just a limitation on how this type editing works.

The ultimate answer to this question is and always will be snapshots. Make hitting Ctrl-5 a habit, and it’ll rarely let you down. This is the direction that linear editing has been heading toward for some time. On the Mac now, for example, many editors are storing changes automatically as you go. At any point you can call up the change log and pull out an old piece to bring it back into the new—but you have to do that, because there is no way for the software to know where it should go any more.

Actually backups are individual projects—the whole thing. You can make a copy of the backup on your desktop, open it alongside your WIP and copy just the pieces of text you need from it—or drag whole items from binder to binder. When you’re done, just close the backup and trash it. Same principle can be used for snapshots. You don’t have to use the roll-back feature—we show it in the sidebar like that for a reason: so you can easily restore localised snippets of text.