cut text that remembers its origin

This is a feature that no word processor has, as far as I know…

When I write I always have a file or two of cuts, where I put nearly everything I cut.

Since I started using Scrivener, I’ve been creating a folder called cuts, dragging text into it to create a new document for each cut then switching back to the source document and deleting it. This works nicely b/c dragging and dropping seems to set a document’s synopsis to the first part of the text, and I can look at the cuts folder as a corkboard to get an overview of everything I’ve cut.

The one problem I have (with the flat file approach and the Scrivener cuts folder approach) is that there’s no way to look at a cut and see where it came from. Sometimes I’ll look at cut text and its original context will be obvious. Other times I’ll look at it and have no idea what I was thinking, making it more or less useless without some way to view it again in its original context.

The proposed feature would be two additional metadata fields called “Source Document” and “Source Context,” a new special default folder Cuts and a new menu command “Move to Cuts” (maybe opt-command-X if it’s not taken). This command would take the selected text, create a new document containing it in the cuts folder, and set the new document’s “Source Document” field to the document from which the selection had been cut, and the new document’s “Source Context” field to the block of text that surrounded the cut text in its original context. The size of the context to include could be set as a preference – maybe 5 lines before and after as a default.

This would make it possible to look at a passage of text that had been cut, and see the document and the context from which it had been cut. I’m getting back to a book project that I haven’t touched for a few years, and something like this would have been incredibly useful…


Thanks for take the time to make a suggestion.

The reason no program has this feature, I would think, is that no such information is provided in the drag. When you copy or drag like this, the information that is put on the pasteboard is taken directly from the text view, which has no idea that it represents part of a document, but only that it has some text in it, and it is placed on the pasteboard as RTF data, which has no way of storing its source. So, when you drop or paste it, the information about where it came from just isn’t there…

All the best,

thanks - I understand the limits of the pasteboard - that’s why I suggested setting up as a separate menu command - it would need to be implemented outside the normal Cocoa drag/drop and pasteboard management. The command would record the containing document name and contextual text, then call the Cocoa cut command, create the new document & set its text to the pasteboard, then set the metadata.

Alternatively, if Scrivener’s Applescript dictionary would let me read the name of the current file (within the binder - not the document name which is already accessible), select text within it, and set text to be an annotation, it would be trivial to write an Applescript to implement this (pasting the source file and context as an annotation in the new document, rather than using metadata)

What happens if the source document changes? Or if, as is very easy to do in Scrivener, it gets split in half? Keeping this metadata updated sounds to me (a non-programmer) like an awful lot of bookkeeping that could very easily go awry.

I can think of a couple of ways to accomplish something similar without requiring re-creation of the Cut/Paste commands:

  • Use Scrivener’s Split functions to split the cut out into a separate document, which remains in the binder as a sub-document of the original. You can use Edit Scrivenings to read the section with the cut back in place, and Compile Draft (or Edit Scrivenings) to create a version without the cut. (This is what I usually do.)

  • Create a Cut document including whatever context you want. Highlight the cut material (or the context), and include a Scrivener link to point back to the original source. Edit the original as normal.

  • Leave the cut material in place, but convert it to an annotation. Use Compile Draft to leave it out of the compiled version.

Happy Scrivening!


Indeed. Endless word-count frustration ensued in very early versions of Scrivener when something as “simple” as the word count for a document was cached instead of calculated for the right-click menu. Keeping a record file on another file that tracks everything about that file is just asking for it!

Katherine’s last suggestion is exactly what I have always done. I preface deletions with "DEL : " in the annotation so I can quickly see what’s going on (or selectively search for them later). Remember it is easy to wipe out all annotations since we can copy and paste without them using the special command in the Edit menu (I snapshot before I do that, though), but simply Compiling without them included is the best option, unless you are a note maniac and your manuscript is littered to the point of illegibility.