Removing text

Question, and apologies in advance if it’s answered somewhere easy. I looked through this forum and the manual.

I want to be able to strip out escaped text in the compile process. For various reasons I do want the to be in plain text exports, which I use a lot, but when I compile a final version. So I went through the manual and decided the Replacements option in the compile with the $@ tag should work. So, I set up a replacement to take either /$@/ or {$@} and replace that with ‘foobar’ (guess what I’ve done for a living before). That’s not working for whatever reason.

Is there a better/easier way to do this? Essentially I’m trying to have a text slug on top of every scene that I can increment and then use that to sort the files when exported, but remove it when I compile. So the first line of text would be

{Act1.Scene2.Foo_Meets_Bar}As Foo walked into the bar, Bar was playing Ms. Pac Man and drinking a Singapore Sling . . .

and then strip out {Act1.Scene2.Foo_Meets_Bar} when I compile. Suggestions? Or is this something really simple that I should have gotten to earlier.

Thanks, Scrivenerers,


If you can do a search that locates these “slugs”, then you can just use that in the replacements field. But I don’t know if Scrivener does anything like pattern matching.

Another approach is to mess with your compile settings. In the compile dialogue, under Formatting, select one of the rows (folder of document rows) that look like your scenes in your binder. Click on the “Modify” button, then the “Section Layout…” button. The “Prefix” box is where you can then enter the magic codes to make this happen.

You might start with the “Non-Fiction with Sub-Headings (Hierarchical)” compile preset (the Format As: drop-down list), if you have your binder arranged with Act folders (or master documents) with sub-documents for scenes. That should have all the numbering you need, and from there, you can just put in the text strings for “Act” and “Scene”.

Once you’ve customized it to your liking, use the “Save Preset” button towards the lower left of the Compile window so you can alternate between that and another preset, depending on what you want your output to look like.

While Robert’s suggestion using prefixes is certainly the way to go if you’re trying to compile two different ways, if you’re wanting the text there on files when choosing File > Export, the way to do this for now will be either with annotations, which you can remove on compile, or by using a search and replace in another program to remove them after compile, as Scrivener doesn’t currently have any sort of regex search tools. Inline annotation formatting can be toggled on and off with the Ctrl-Shift-A shortcut or via the format bar or Format > Inline Annotation menu command. When you compile, deselect the “include inline annotations” checkbox in the Comments/Footnotes tab.

EDIT: Aha, I was completely wrong about what I originally said (now deleted) about the replacements tag. Teach me to try and answer issues without enough caffeine in my system to de-fuzzify my brain. :wink: However, the upshot is the same, because what I think you’re trying to do with the replacements can’t be done. That is, the $@ tag is used to hold a certain, dynamic bit of text from the search and use it in the replacement, the idea being that you are replacing surrounding static text. So for example you might write ^blah blah blah^ and then run a replacement for ^$@^ and replace it with $@. You can’t currently use the $@ tag in the search to and then replace it with nothing, which sounds like what you’re going for. So annotations are still going to be the way to go for now.

@Robert - excellent explanation. Thanks much, good stuff.

@MM - if I had a nickel for every time I could have improved a response post-caffeine, I’d have a lot of nickels. I think annotations will work, but if not, I can always export to another app, as you say. In future versions, though, a little regex love would not make me sad . . .

Building a more robust search feature is something we’d like to do down the road; it’s just quite a complicated task and not something we could delve into straight off with 1.0. But we certainly agree it would be useful and have it on our list.

Tested this late last night. Using annotation text worked perfectly. Thanks very,very much.


Great, glad that did what you needed!