Remove Text with Place Marker/Placeholder

Scrivener
,
1

Hi All, I’m discovering all the wonderful things about Scrivener (including these forums.)

One thing I find missing (or maybe I just haven’t located it) is a way to pull text out of the main body of the document, but retain a marker for its place so that it can easily be put back if necessary.

For instance, I’m considering cutting a paragraph but I haven’t decided yet. I need to test the flow of the text without it. So I pull it out, but its place is still marked. If I decide to put it back, the location is still referenced.

It might be akin to Word’s Review mode, when you delete text but it remains in the margin as a markup.

Does something like this exist? Thank you!

(I’ve tried a few workaround strategies, but none seem quite right:

  1. Putting it in a Comment. Two issues: a. I have to cut and paste the text into a note format; b. The note has to bind to a character in the main text. I usually use a . [period] but then when I print a draft the text is littered with stray periods.

  2. I’ve also tried moving it to the end, or to a separate chapter, but then I lose the location reference.

  3. Lastly, I’ve tried using Snapshots, but this doesn’t zero in on one specific piece of text, nor seem to locate it where it was. It’s useful to maintain a version prior to a heavy edit, but I don’t think I’m using Snapshots the way they’re intended.)

2

Regarding Snapshots—that is an approach as well, though it might be a little unwieldy for something like this since the snapshot covers the whole chunk of text at once. Be that as it may, the one downside you mention is actually not a huge problem because of that “Compare” button at the top of the Snapshot inspector tab. In comparison mode, you can use the arrow buttons that will appear alongside it to jump from one edit to the next, and tweak the granularity of comparisons with the gear button.

Inline annotations as a soft-delete

What you’re attempting to do is what I consider to be one of the prime advantages of Scrivener’s Inline Annotation feature. The idea is that the text you put into an inline annotation exists right within the context of the text around it, meaning that you can use the feature to selectively remove bits of text when compiling, without moving them.

To use it, simply select the text you want to remove (including the carriage return if it is a full paragraph—triple click works well for that) and hit the ⇧⌘A / Alt+Shift+F4 shortcut (or use Insert ▸ Inline Annotation). The text will be marked in a clear and easy to identify manner. Restoring the text is a very simple matter of using the same shortcut to toggle the annotation formatting back off. In conjunction with that is a helper tool: Edit ▸ Select ▸ Select Annotation, where you can just put your cursor anywhere inside the annotation and use that to select the whole thing and toggle it off. I use that often enough that I’ve assigned my own keyboard shortcut to the selection command. I use inline annotations to mark “things to do”, and selecting and deleting them is how I “mark them done”.

Another advantage to this method is that you can search for them. The Edit ▸ Find ▸ Find by Formatting... tool has an “Inline annotation” search method that can even isolate by colour usage or text found within the annotations. I use a special colour for “soft deletions” like this, so that I can readily see what I meant to accomplish with it, as opposed to my other many uses for this feature.

Striking out text

There is another approach you can take as well, and that is rather intuitively the strike-through feature (shortcut Ctrl+/ / ⇧⌘-). By default, text marked this way will continue to compile, but by setting Delete struck-through text in the general options tab of the compile overview window, you can turn that feature into a functional one. And if you use Revision markings (Format ▸ Revision Mode), strike-through will use the current revision colour.

While you’re looking at that area of compile, also not you can choose to print inline annotations rather than remove them. If you do want to see the full text, that option is available to you.

What if you well truly do not want the deleted text any more? You could go through and selectively delete them permanently, but both overstrike and inline annotation methods have mechanisms for permanent removal within the current selection:

  • The Edit ▸ Copy Special ▸ Copy Without Comments and Footnotes in fact includes inline stuff as well. Follow that up with a simple Cut and Paste to strip out all markings from the text. Naturally—not a good approach if you use footnotes!
  • The Edit ▸ Text Tidying ▸ Delete Struck-Through Text command is the permanent version of the option in the compiler.

Now prior to do either of those would be an excellent time to make use of the Snapshots feature. :wink:

3

Yes! Wow! You are amazing for introducing me to this. :smiley:

I’ve been using Scrivener for two years and churned out hundreds of pages, and there was the tool I was missing right under my nose. I’ve littered tons of pages with clunky workarounds. Should have read a little deeper in the user’s manual, I guess (but I’ve always been a learn-on-the-fly type.)

Thank you. I’ll give Inline Annotation a try.

M

4

Amber V, so now I’ve played with Inline Annotations a bit. It seems great!

However, is there a way to toggle the annotated bits so that they don’t appear in the text as it’s being edited?

I’ve figured out how to make a section an Inline Annotation: Format > Inline Annotation. I’ve added the Annotation button to the toolbar.

But I can’t see if there’s a way to toggle these visible/invisible. Also, you mention Insert > Inline Annotation. I can’t find that particular function. Only Format > Inline Annotation.

Thanks!
M

5

Also, I religiously use the Project Targets dialogue for both first drafts and editing. It keeps me honest about word counts.

But is there a way for Inline Annotations to not be registered within the Project Targets? Or subtracted from? For instance, let’s say I’m trying to edit down to 90,000 words from 100,000. Ideally, I’d like to use the annotations to see what big chunks of text I could remove to get me there.

6

The inability to actually remove text from the text editor in a way that doesn’t delete it is one of the factors that lead to the creation of the sidebar Comments feature, years ago. It’s something we always wanted to do with inline annotations (and perhaps inline footnotes as well for that matter), but after consulting with Apple’s engineers they affirmed that there is just no good way to “fold” or “hide” text without a huge mess of ugly workarounds.

Ah you must be using version 2 then. We moved a bunch of things into a central “Insert” top level menu, gathered from scattered places in the Edit and Format menu. That also means my instructions on compile settings will be a little off. You’ll need to look for overstrike deletion in the Transformations, and annotations in the Footnotes & Comments compile panes.

Not in a live fashion, for performance reasons the real time counter has to simply count what exists in the editor. But if you click on the stats in the footer bar you can get a count sans annotations, and as well the Project Statistics feature will also omit them. Neither is live, but for periodically checking on how well the editing process is going, I find them suitable alternatives.

7

Thanks for all your insights and help!

As I’ve thought about it, one thing that would benefit me tremendously (and maybe others) is similar to the Comments feature, but a variation on it. It might be labelled “Review” or “Inspect” or “Cache.”

Here’s how it would work: if I select a block of text, a right-click dropdown or keystroke would offer the “Cache” option.

When selected, that block of text would automatically be removed from the body of the text and moved to its own new pane on the far right, next to Notes, References, Snapshots, et al. It would be very similar to the Comments pane. A searchable but non-compiled symbol would be added to the body text at that point that would allow one to find all “Cached” pieces of text.

There may be a strategy to modify the Comments to effectively do this. Am I being too nitpicky? I guess the issue I have with using Comments for this function is that it takes several steps to do what could effectively be one step: I have to cut a piece of text, type a symbol (such as a period), select it, make a Comment, and insert the text below my name and date. The symbol still compiles in the text—if I have enough of them, they can really litter the body of the writing.

For me, Comments feels like a cludgy workaround for saving cached pieces of text that I might either remove or keep. Inline Annotations is great, but by keeping the text in the body (even if a different color) it impedes the readable flow of the text, especially if the Annotation is large/long.

What do you think?

8

Keeping in mind that we’re already talking about an introduced layer of mechanism and complexity between editing text directly and indirectly, do we really need degrees of how not-to-really-just-delete-text? Or is this perhaps a problem that is at its roots very simple, and can be as elegantly solved as one would by slashing a red line through text on a sheet of paper?

This is perhaps subjective, but I would agree with you that comments are not a good tool for this job—it’s why I don’t recommend them for it, and I think the problems inherent in that model go far deeper than the procedure involved in using coments as-is. I don’t think there is better way, mechanically or psychologically speaking, of soft-deleting text than marking it, as it was originally written within the text around it. In contrast, there are so many issues with the notion of “anchoring” deleted text to other text in that all text is volatile. It can become eligible for deletion itself, or movement, which would then require one to cross-reference alternate texts within anchor points to make sure the moved text makes sense with the deleted text anchored to it, and if not, move the deleted text’s anchor point to some other piece of text where it should be left behind, &c. The mental burden of editing accumulates when every edit must not only consider the text as is, but the text as it were and all points of its evolution in between. These are fundamental problems with the model itself in this application. These are not problems that are solved by a reduction in keyboard shortcut usage, or bad adding more complexity to the model by introducing types of comments and separate panes for them.

To my mind, a cycle of edits where the removal of text is represented as markings is best expressed in the full text, at that point of time, so that one can see the justification for its removal by being able to read it in a linear fashion, or to read around it as need be. Once the time has passed for the evaluation of whether the deletion is justified or not, the text is physically removed and the previously marked copy archived for future posterity (snapshots). One leaves behind a trail of fully readable copies that show what had been previously deemed worthy of being written (and later deemed worthy of revision).

The moment you start thinking to yourself that you really need to always be reading the text without the deleted text in the way—isn’t the real question then: isn’t time to move on? To delete it? :slight_smile: Again, it’s not really going anywhere because that’s what snapshots are for.

It’s simple, elegant and does everything it needs to without any complications—offloading everything that should offloaded to wetware, while adding mechanics to the digital process where that is best done.