Hello everybody,
KB spoke sometime about a new feature: styles.
I’d like to know this: will be possible to make a “search” in all the binder (or just in some parts of it) looking for all the instances using a specific style? (as in Word for example)
Thanks and keep up all the good work! 
Edit -> Find -> Find by Formatting.
Katherine
If I can suggest, it would be helpful if that were expanded to find ‘no’ formatting. In other words, to have the ability to search for moments where there is no style applied to parts of text.
I realize that many do not apply styles to very many elements in text, and searching like this would not be of any practical help to them.
But not everyone uses styles like this. and Scrivener has a history of being designed for everyone. It’s all-encompassing, at least to a degree, which I appreciate. In that spirit, it could be even better if this feature were expanded.
I, for instance, apply a style to everything, which allows narration to have first-line indents and dialogue to have all lines indented. I also sometimes forget to apply a style during revision, and part of the reason is that text with no style can look identical to text with a style attached to it if indentation is the object, if the line of text is not long enough to wrap.
This usually results in a nasty little surprise once compiled as epub or mobi, where the wraps are quicker and the page formatting is at the whim of the reader, rather than fixed, as on a hard copy.
But if I could search for ‘no style’, that would allow a pre-emptive strike against this.
There are ways you can set up your default formatting, project styles, and your compile settings to work around this issue so that you really do only need to apply styles to text that somehow differs from norm. However, it would be nice to have some way to see which text had no format applied at all – maybe instead of being part of the Find process, a special view overlay that would temporarily highlight all text that had no style applied?
Jack,
As Devin says, you are complicating the process a bit by having a style for every single bit of text—the reason why body text isn’t normally given a style is precisely to avoid problems with compilation and allow the different compilation body text formats to apply automatically. It can be done, of course, but it’s easier not to.
But to answer the specific question; you can identify all bits of ‘No Style’ text in one go.
a) Highlight a paragraph which is already in ‘No Style’.
b) Bring up the Styles Panel (Ctl-s)
c) Click the gear button and choose ‘Select All Style’.
This will select all the paragraphs still not having any style associated — it works on Scrivenings as well.
HTH.
Or, based on the fact that ”no style” is supposed to be the default status, highlighting all text that does have a style?
I am one of those users that seldom use styles in Scrivener (as opposed to in Word) and highlighting all that instead of the few styled pieces seems illogical.
It’s possible to define a highlight box as part of a style: any text with that style will be highlighted in the color you choose. (Only in the Editor for your use, not in the output document.) See Figure 15.14 in the Mac Scrivener 3 manual.
Katherine
That is why the thought was that it would be a non-default temporary view overlay, so most users would never see it. But if it could be toggled so it could highlight para styles, character styles, both, or no style, that would be super useful too.
You want the View → Text Editing → Show/Hide Markup command. Assign highlight colors (as above) to the styles you want to highlight. Use Scrivener → Preferences → Appearance → Textual Marks to define which markup is hidden. Done.
Katherine
Cool! Learn something new every day!
I thought this might work. It does, but it still requires scanning through the manuscript to find everything with ‘no style’. and many items that style apparently can’t be assigned to, such as single carriage returns, dividers, etc., are then also highlighted. Once I find something with no style and correct that, then I have to create a new line of text with no style to give the function a target to search for.more instances. So sadly, this doesn’t really help much at all.
It’s actually easier to do what I’m doing, which is to compile and scan the epub/mobi for frighteningly-large type, which is what unstyled text appears as for some reason, but only after being compiled.
Regardless of the replies I am getting, I dream of the day when the help is constructive, rather than cautionary, which really does not solve the issue. I clearly stated why I use styles on most text:
I don’t relish quoting myself, but there it is again, plainly stated.
Whether this is the common choice by other users or not is pretty much beside the point. Whether it might seem illogical, is completely beside the point. That it complicates things is also well-understood by me (even if it appears that Scrivener gurus never foresaw this possibility or this need, and wrote the software in a way that does not accommodate this need).
The key adverb here would be ‘needlessly’. if this is the only way to accomplish what I need to accomplish, then in no way is this application of styles being done ‘needlessly’. I need a solution. Currently, this is the only one I have.
But I would welcome a better solution than using styles on all narration and dialogue as a way to differentiate them from each other by format. That is the goal, regardless how I might achieve that. So far, this workaround seems like the only logical way. If there is a better way, a reply that revealed that would be constructive.
One possible solution is to find a way to make unstyled text stick out so that it can be noticed, upon which I would correct the omission of the style. Currently, it is invisible to me. For instance, if a highlighted box (which is a brilliant idea, thank you, Keith, that I use to make sure a word has Emphasis rather than is simply italicized), were able to be placed around unstyled text automatically, that would solve this problem instantly.
Or, if there were some way to have unstyled text appear in a different font size, so that I could see it stick out, apply a style (that includes the proper font size), and fix it once and for all.
You can set your “no style” text to be formatted any way you want, both while writing and after compile. You simply define it in Preferences, with font, indents, whatever.
The reason you’re not satisfied with the suggestions you get is probably because no one understands why you need all text to have a style while you write, and therefore everyone tries to answer from the way they understand your description.
If your “no style” text looks strange after compile it sounds as if you don’t reformat it during compile, to make it look the way you want. Are you using compile “as is” for all your text?
Jack,
The reason why people point out that it is unnecessary to associate a style with every paragraph is that it can lead to exactly the sort of complications you are having. They are not trying to annoy you as you seem to believe: they are trying to help you to get the most out of the program. [1]
As for your specific problem, AIUI, you need to:
identify all lines of dialogue which do not have ‘Dialogue’ style and convert them, then
convert all the remaining ‘No Style’ paragraphs to ‘Narrative’.
You could try this:
Create a new style (called, say, ‘DUMMYSTYLE’ - the name is irrelevant) and make it distinctive (eg colour = green)
Redefine your current styles to be distinctive (e.g. Narrative is blue text, Dialogue is red). Doesn’t matter what the distinction is, as long as DUMMYSTYLE, Narrative and Dialogue are distinguishable from each other to make recognition easier. Make sure that both Narrative and Dialogue have a shortcut (for the sake of argument, cmd-alt-1 and cmd-alt-2 respectively).
Go to a current ‘No Style’ paragraph and as before Edit > Select > All Style to select every one of them in the document. Then allocate the selection to the style DUMMYSTYLE. You should now have no ‘No Style’ paragraphs left.
Go to the top of the document / Scrivening and select[b] Edit > Find > Find by Formatting /b and fill in the dialogue as follows:
Find: Style
Containing Text: [blank]
Search in: All Documents
Style Name: DUMMYSTYLE
Press Next or preferably shift-alt-cmd-G to find the first occurrence of ‘DUMMYSTYLE’ style. Change it to Narrative or Dialogue as required using the relevant short cut.
Repeat shift-alt-cmd-G then cmd-alt-1 or cmd-alt-2 until you’ve reached the end of the scrivening.
When you’re happy that you’ve converted all the DUMMYSTYLE-styled paragraphs, redefine the Narrative and Dialogue styles back to their original format.
In this screenshot, I’ve just found the first occurrence of the style DUMMY, ready to convert (cmd-alt-2) to Dialogue. Then shift-alt-cmd-G will move the selection to the next DUMMY paragraph (Neque porro…) to be converted to Narrative with cmd-alt-1.
This will be repetitive, but it’s only a matter of repeating shortcuts and you shouldn’t have to use the mouse at all. At the end you should have no TEST or No Style paragraphs left.
Of course, all this is a workaround to the fact that ‘Find by Formatting’ doesn’t offer a ‘No Style’ option, but I’ve tested it and it seems to work well enough, pending any decision by the developer to add the feature direct.
Hope this helps.
[1] From your description (which is all we have to go on, of course), the reason stray paragraphs of ‘No Style’ are being rendered in ‘frighteningly-large type’ is probably because every compiler format makes an automatic conversion from ‘No Style’ in the editor to the standard paragraph style for the compile format you chose.Of course you can override this, when it’s necessary, but in your case it’s really not necessary. If you have had every ‘narrative’ paragraph as ‘No Style’, the conversion would still go through to the format’s standard body text. If you don’t like some aspect of that, you change it in the compiler, not the editor. This is a key feature of Scrivener and it’s why you can usually write with say green Comic Sans 15pt as your default style in the editor and then compile to a manuscript in Courier 12, to a paperback in Palatino 9pt and to an ebook without worrying about the details of how the body text will appear.
That’s probably not going to help you with your immediate problem, but understanding this will help you (and anyone else following the thread) for future projects. Make your most common paragraph format the ‘No Style’ default and only use other styles when necessary. It saves unnecessary faffing.
This is a lot to think about.
Thanks for your diligence in trying to help. I’ll report back, but these ideas are interesting, probably helpful.
And I must apologize to Tomkeen. I honestly did not set out to hijack your thread; I was actually trying to just bump it up. 
All righty then.
I may have not followed the suggestions religiously, but I’ve solved the problems. This is coincidentally how many writing problems are solved—someone makes a suggestion that takes you out of your own thinking pattern and allows you to come up with an even better idea than the suggestion.
Better? Not assuredly, but this problem escalated. Today, I discovered that some projects were not creating the frighteningly-large type effect in epub/mobi. That was surprising, since all 4 of my projects use identical compile settings and identical templates.
But that is an even worse problem. At least the large type alerted me to missing styles. It turns out I’d missed dozens of no-style lines that did not display, after compiling, in large type. The styles I use are only subtly different, and no-style, narration in unwrapped lines, and dialogue in unwrapped lines can look almost the same, depending upon where it is being viewed and whether the reader has set the type size larger or smaller.
I wasn’t about to hold my breath for Scrivener to address this. They don’t seem to understand why it’s even a problem, let alone have motivation to address it. That’s ironic, from a program that tries to cover all the bases and typically excels at that. Scrivener is still absolutely the king. No one else does it even close to this well.
If anyone is facing similar problems, maybe this can help:
I decided to embrace the concept of imported styles. I created a small project with the three main styles that have been problematic for me, each in a single short line. Then I gave them different primary colors, so they would stick out. Then I duplicated that project and redefined those styles with black type only.
I imported the colored styles into my 4 main 100k-word projects, then went full screen, set the size to 75%, and just scrolled the entire manuscripts. When I found black type, that meant there was no style applied. I fixed them all, then imported the black-type styles to get back to all black type without changing the style formats beyond the font colors.
IOW, the styles were then all formatted properly, but with different font colors, which was then fixed by importing black-type versions of those styles. Problem solved.
Then I changed the default font to a light purple, so that when I revise, edit, add new lines, those will stick out and remind me to apply the style they need.
These may not be the concepts that were suggested, but what was suggested inspired me to find a fix, so thank you for that.
Now, let’s set the record straight and clear up what appears to be a mystery to some:
First, it IS INDEED necessary to associate a style with every paragraph if you want dialogue to have a different format than narration in fictional prose text, or at a minimum associate a style with one or the other of those. That’s the very definition of a typographical ‘style’—being unique and displaying type differently from another style, and that is exactly what I’m trying to do.
Second, this will be the third time I’ve been compelled to repeat that I am fully aware what the complications can be, and that this is completely beside the point of solving this issue. The fact that it brings complications has nothing to do with the fact that it is still a problem. Did I throw my hands up and whine about it? No, I put my head down and fixed it.
Third, I don’t assume people are trying to annoy me on purpose. What motivation they might have is not clear, and I’m happy to give them the benefit of the doubt.
Fourth, understanding the above three things is the secret to actually being helpful, if that truly is the goal.
Fifth, being admonished by people who don’t understand what I’m saying, very clearly, is indeed annoying, as is jumping to conclusions regarding what I believe about them. My only conclusion is that it is quite obvious no one is really paying attention to what I am saying.
Sixth, I love this forum and I love Scrivener. It does irk me that it was written in a way that has made me have to search for elaborate workarounds to accomplish what I have accomplished, but I consider that just that they never considered this particular application of this wonderful tool, and wrote it in a way that ignored this. That is often referred to as an ‘oversight’.
But that’s not something I blame them for, or even something I expect them to address—just something I expect them to step up and take ownership of. And after all, how did I fix this? By using other features built into Scrivener. So they can take credit for that, if it might make them feel better, and those who suggested what they suggested can also take credit. I’m in everyone’s debt, even if I had to finally fix this issue myself.
I am not being stubborn, I am being resolute. There is a difference with a distinction there.
No, it’s not. You don’t need to have a Scrivener style associated with every paragraph. Every paragraph can still have a specific formatting, different for fictional prose and dialogue. The most common type of paragraph would be “no style” and the other would have a style associated, and the “no style” would have the format you decide in Preferences, while you write. When you Compile you decide in the same way the format of the standard “no style” text and another format for the styled text. Simple.
I have to disagree here.
Your manuscript is your manuscript. Use whatever formatting facilitates your goals.
But if you choose a formatting approach that is directly opposed to Scrivener’s design philosophy, it is perfectly legitimate for people to respond to the inevitable complications by saying, “Sorry, that’s not how Scrivener is designed to work.” Your opposition to Scrivener’s design philosophy is not beside the point, it IS the point.
Katherine
Some history that I don’t know if you are aware of (apologies if you do, but others who are reading this thread may also not know/remember this history): originally, in the Scrivener 3 beta for Mac as styles were being introduced, for a time Scrivener operated under the concept that every bit of text did have to have a style. That ran into later complications for a few specific use cases that existing Scrivener users depended on, the details of which I do not remember at this time because I am not one of those affected, and KB realized that it could be solved by not requiring a style.
Note here that when Scrivener uses the word style, it means something very specifically in terms of the metadata that is stored with the data. Scrivener uses RTF as its base data format. Native RTF (if I remember this correctly) doesn’t support the concept of styles at all; when you change styles in a program, it embeds the necessary codes to represent all the attributes that style sets in the raw RTF.
But what happens when you change that style definition? In a program like Word, the styles are defined in one place and then when you apply a style, the document metadata for that text shows the new style (and the switch back when that style ends). This is why Word has its own data format that is not RTF (modern Word is XML, previous Word formats were a weird super-set of RTF but with more differences, and they produced incredibly fragile, corruption-prone documents as a result.) Because of that, when you change the style definition in a Word document, Word doesn’t have to go update the actual text data in the document; it changes the style definition XML and re-renders the changed style everywhere appropriate. If you save that Word document to RTF, though, it has to go convert all those style references to the actual text properties they represent. (I believe, but could easily be wrong, that Word will save an enhanced version of RTF that keeps the style references intact so they can be re-read by Word if you read that RTF document back in, but it has to add in the explicit property data everywhere so the document can also be read by programs that only read standard RTF.)
So that’s the fundamental problem that Scrivener had to solve – being based in RTF, if you use styles, you basically lose those style definitions the minute you save the RTF document (without doing custom extensions like Word) as they are converted to the corresponding sets of properties. And that’s how text presets worked in Scrivener 1 and 2 – they were literally just pre-set bundles of text properties, which got stamped all together when applied, but if you changed the preset definition, none of the previous uses in your project got updated because there was no definition to tie them together.
So in Scrivener 3, styles serve two purposes: they allow you to use styles like Word and other programs where the definition of the style and the application of the style have a link, so that if you change the style definition you change the application everywhere that style is used; they also make it easier for the Compiler to pass style information on to formats (like Word, etc.) that understand and use that information. But, KB determined that putting styles on everything caused deep problems for specific use cases.
So now Scrivener 3 has the “default formatting” on a per-project basis. When you write a new chunk of text, it will use this default formatting (unless something else overwrites it) but it does not have a style associated with it. So if you change this default formatting, it acts like the old Scrivener 2 – you change the way future text appears, but you don’t change any of the existing text – the default formatting is just a preset. Anything you do tag with a style works the way we expect styles to work – update the style definition, all text marked with that style changes. This is important when it comes to compile time, because the style names get passed through (and if I name them to same as the styles in my style sheet in my target format, I can override the Scrivener-provided style definitions and use an external style sheet without having to duplicate all the intricacies of those style sheets in Scrivener). And if I remember correctly, everything that isn’t formatted with a style will get passed through Compile using the Compile format defaults, and I believe that it gets tagged as Normal style in outputs that expect styles (or at least, there is a way using the Compiler overrides to make that happen) – so in my output format, I get the effect of all of the rich style awareness.
One example I have seen of how this works in a more complicated setting. Our writer wants to have drop caps for the first paragraph at the start of every new section, with every subsequent paragraph merely having an indent. Rather than try to do elaborate drop caps in Scrivener, they simply indicate this by not indenting the first paragraph of each section. They are using a fairly common setup – folder per chapter, a separate document for each section in the chapter.
To get this to work, they set up Scrivener so that the default project format is the desired typeface, size, with no leading indent. They then define a NonLeadingPara paragraph style that is the same settings, except that it includes the desired leading indent; this style has the checkbox marked so that following paragraphs receive the NonLeadingPara style. Now, when they create a new section and begin typing, Scrivener does not apply a style, so that first paragraph receives the default formatting (no indent). When they begin the second paragraph, they apply the NonLeadingPara style, and every subsequent paragraph they type in that section automatically uses that style. If they have specific lines of dialogue or other internal formatting that they want to distinguish, they set the appropriate styles for those and apply them as necessary.
Now, that’s one way to solve their problem, and it has a few advantages, but they can also reverse it – the leading paragraph gets the style definition with no leading indent, and the default formatting gets the leading indent. NOW…they only apply the style to the first paragraph in the section. Any other paragraphs they write don’t need a style unless they have those other styles they need to apply. And now, given how they set up their Compile format, the leading paragraphs get their style passed into the target Word doc, but the majority of the body paragraphs (which have no style) become Normal style in Word.