I am working on a very large project and have extensive, project-wide changes to make to the manuscript to replace entire text modules.
Extremely useful to the process would be wildcards for whole words. If Scrivener already provides this feature and I just haven’t found it yet, please excuse the question.
The requirement is:
[text section 1] [any character name] [text section 2].
In the project-wide “search and replace” routine, the [any character name] should be replaced by a wildcard, for example [*] and kept, while you can replace [text section 1] or [text section 2].
Concrete example:
Search for: “* asked excitedly”.
Replace with: “* said excitedly”
Results after run:
[…], Michael asked excitedly. → Michael said excitedly.
[…], Paul asked excitedly. → Paul said excitedly.
[…], Mike asked excitedly. → Mike said excitedly.
… and so on —
Oh, I haven’t used regEx yet. That’s a great option.Thank you for the hint.
Is there also a possibility, to set specific words fron regular to italic?
I’d like to change spaceship names project wide to italic.
Ex.:
Enterprise → Enterprise
Do not believe can do in project replace but could use find in text and in every instance replace with italic version. The true issue will be in compile which overrides the scrivener text formats except if keep file AS IS
Standard font formats, such as regular, italic, or bold, are not overwritten by the compiler, provided the target font (as specified in the compiler) supports these formats. Overwriting happens only when styles are used that are not mapped in the compile format.
No, there is no non-tedious way to change formatting in a find/replace. You’d have to find and step through the instances one by one and apply formatting to them individually. I’d recommend creating a style for the purpose first, give it a shortcut, and apply the style to each instance,
I understand how you mean it, but don’t want to use styles in my documents. I’m in favor of separating content and format as originally intended in Scrivener and adding text formatting only in the compiler. It would be too time consuming to change that afterwards, as the project file is already very large.
If you can use Markdown in your final compile, then it’s possible to search for Enterprise and replace with *Enterprise* (Enterprise) or **Enterprise** (Enterprise).
The freedom and euphoria of separating content from format.
In projects that I will compile through MMD, the only paragraph style I use is Blockquote. I have created an “Emphasis” character style, but since using the usual italics gets converted on compiling as I have “Convert rich text to MultiMarkdown” and “Escape special characters” turned on, I don’t use it. Binder hierarchy deals with heading levels.
For projects to compile to RTF, I use Blockquote, and an “Ingredients” paragraph style for my recipe project. I also have a “No Indent style” so that paragraphs following headings and blockquotes, etc. don’t become indented when I apply my style sheet in Nisus Writer Pro. Headings are defined, but applied by the compiler.
But that’s it in my usage. I would suggest that my use of styles is essentially semantic, rather than formatting, as they tell the compiler, and in the case of RTF documents, my word processor, how the text should be formatted. So content and formatting are essentially separated in Scrivener.
I’ve been using Scrivener since the beginning and have always found the concept of writing on the manuscript from formatting via compiler to be the better approach.
Within my project, which has grown enormously in the meantime, I use only one standard working font for the typing work. The only formatting I use when writing is italics and occasionally bold.
The finished product is generated with the compiler. This allows me to create any version and formatting from the same manuscript, whether a standard page, eBook, paperback or hardcover.
I would be happy if there was a format based search/replace function within Scrivener. Of course, I could output all the documents in another format, edit them with another tool, and re-import them, but that would be extremely time-consuming given the size of the project.
Maybe the developer will implement such a function for a future version.
Makes sense. I was just curious why you’re considering styles as something that gets in the way of this approach. The obvious use case is to “style” something (in the editor), but IMHO that’s not the real beauty of them. They can be used to “markup” text for the compiler to handle.
At one time Scrivener did have a setting in the Editor that converted RTF to Markdown, and Markdown to RTF. That meant that it was possible to search and replace by formatting because users could switch between writing engines, make semantic-driven changes, and then switch between writing engines again (if necessary).
Now you can do some of these things during compile, but that brings issues with the order of how elements are processed during compilation.
Your post explaining why you work the way you do mirrors my sentiments. For the reasons you gave, I mainly use other writing tools these days. I don’t like to put the icing on the cake when I only have a stack of eggs, a bag of flour, and a heap of sugar. I don’t want to see or think about the decoration until I have made the cake. Styles encourage a focus on WYSIWYG publishing rather than writing. And when writing, I just want to write; not think about the packaging and sales numbers.
I’ve been using Scrivener for a long time, and I don’t recall ever seeing that option.
However, it has always been possible to use whatever markup you like in the Scrivener editor. It’s only plain text, after all.
I would encourage people arguing that “styles encourage a focus on WYSIWYG” to read (among other things) Section 24.5.3 in the (Mac) Scrivener manual. Styles, as implemented in Scrivener, are a very powerful tool for post-processing your output document, exactly the opposite of the WYSIWYG approach you’re seeking to avoid.
Actually, that’s exactly the point I am making. We just see the same things differently.
As you say, styles ‘are a very powerful tool for post-processing your output document’ which (in line with your observation) explicitly encourage users to focus on the output and the eventual WYSIWYG or ‘what you style’ of the final document. Styles really mess with the writing experience: they actually grind it to a halt. Of course, other people love them. We’re all different.
Editor styles don’t necessarily format anything; they serve as semantic information. I use a style for emphasis, a style for curse words, and a style for dialog transmitted across the 2099 version of the world wide web. They delineate kinds of text, enabling Compile to intelligently format it as needed. It really is the opposite of WYSIWYG.
