First off - I’m on Win11 Home & Scriv. 3.1.5.1 (No MS Office is installed, using Libre instead)
How could I best address the following:
I use another program that uses double square brackets [[xxx]] to denote information that (optionally) does not print those details for privacy purposes. For my personal use, the program strips the double brackets and outputs all the detail(s). For public/sharing purposes, it will either output “Living”, or just omit the information entirely depending on the audience.
In the same program, I use single brackets [xxx] to denote anything that needs tweaking/updating.
Can anyone suggest a best practice to get all these documents into Scrivener and still retain some method to mark their intended usage without conflicting with any other formatting/compile conventions?
I am thinking that maybe I should run them through an external editor (Libre) first, and find/replace them with a dummy style or formatting/text/highlight color, say “Living” or “needs edit” so I can address the issue at compile.
However, there are multiple docs (100s), and ideally I would want to get them into a Scrivener binder first and do a search/find/replace instead of one doc at a time. (Or maybe utilize Libre’s master doc feature?)
Does anyone know if master docs from Libre import into Scrivener’s binder successfully?)
Caveat - output will be in multiple formats. Docx, pdf, epub, paperback, and/or POD. I am a beginner at coding/compiling for multiple outputs. I am assuming I will need to incorporate some sort of if/then structure? How would I do that for all these particular scenarios?
Sound idea; and for anyone not au fait with regexes it’s worth knowing that, if you tell it which flavour of regex to use (can’t recall Scrivener’s standard off the top of my head), chatGPT (and no doubt others) are quite good at generating regexes from natural language descriptions of what you want to do.
Reg-ex - is new to me. I have no clue how to create one. This I need help with.
That said, I’ve seen other posts where double square brackets are used for coding wikilinks, and have also seen the use of square brackets for other code. I am concerned that if I retain them all in my WIP until compile, and need to use the other conventions, everything will get all mixed up.
Possible solution? - If I imported all these docs from the other software into their own project and used reg-ex to change the bracketed text to another (code/style/format?)
I could then compile to (rtf maybe?)
Import the compiled version with its updated (code/style/format) to my WIP
Create new reg-ex for my WIP that addresses the ‘new’ (code/style/format) in the final output.
The wiki link feature in Scrivener is a typing aid rather than something that persists after you type. If the setting is enabled (found in the Corrections tab of options), then as you type [[binder title]], the final bracket triggers the behaviour, creating a hyperlink to ‘binder title’, and removes the brackets. So this feature in and of itself would not conflict with your material, should you choose to use it.
Regex would solve optionally removing the text when you compile, it is a text search tool, not a formatting tool. For example, you could replace \[\[.*?\]\] with nothing, which would strip the brackets and anything between them out of the compiled copy.
A more Scrivener-specific approach to this problem would be to use an Inline Annotation to mark such texts. The way you describe using it is pretty much exactly what inline annotations do. They are personal comments that are stripped out when you compile by default. You can however set them to remain, and also adjust their appearance with a prefix and suffix field, which would give you a place to add the double-brackets for the other software. The switch itself is a project setting, under the general options tab on the right side of the main compile overview window. The settings to change how annotations output are found in the Footnotes & Comments compile option pane, when in the format designer window (and the format designer is also where you would want to add the replacement).
But as noted, there is no automatic way to go from text containing [[notes like this]] to styled or annotated text. That is something you would have to do with search, implementing the formatting as you go, which would probably be rather tedious without a macro to help.
So for existing content, if I were in your shoes, I wouldn’t bother with changing anything. I would just add the regex replacement to my compile Format that is meant for producing content for others, and have a second format without that replacement, and perhaps the inline annotation settings adjusted to produce brackets on output. That way you could adopt the more Scrivener-native approach for future notes, without losing the functioning of anything already there. Or you could just go on working as you have—either way works really, though of course you wouldn’t be able to use the wiki link option if you go with typing them in while writing.
Can someone else tell me 'which flavor" of reg-ex I should be using?
Reg-ex is completely new to me; I had to look it up when I saw it mentioned in the forum. However, I am not totally ignorant of all coding, and well understand and use structure and syntax to create advanced excel coding all by myself.
I found this website.
Does this look like a good starting point to familiarize myself with reg-ex? Does anyone have a better suggestion?
Scrivener for Windows uses (mostly) PCRE-compliant regex dialect (the stuff it doesn’t support is pretty arcane). Where you will notice it is not nearly as capable is in the replacement field, which only provides basic dollar-sign insertion of captured text from the search pattern. For example, \[\[(.*?)\]\] adds parentheses around the text capturing part in the middle, which stores the text into $1, which can be typed into the “with” field. Thus that could turn into: <!-- $1 --> to make it an HTML comment with only the brackets stripped out.
You can see how this does nothing for formatting, at this point. It’s just a really fancy wildcard syntax.
Replacements are limited because our regex engine is only provided on the parsing side. It does store captured text into variables that we can make use of, but doesn’t even support the syntax for inserting it. That had to be added by hand.
And yes, the regex tutorial you found is one of the best on the web.
Do note regex support is in the Find panel too. So you can test your patterns without having to compile over and over.
Thank you Ioa for the explanation and clarification of wikilinks. Makes sense, and understood.
I do use inline annotations for this purpose when writing direct in Scrivener :
What sort of prefixes and/or suffixes would I use on inline annotations? I need a tutorial (or a manual page) on prefixes/suffixes I’ve also hit some stumbling blocks in the compiler with prefix/suffix settings. I need to start at the bottom - I am not (always) grasping what the purpose or meaning is of prefix/suffix combo’s or how to “read them” when they exist in samples. I need a good explanation of the general concept, expected syntax, and a list of possible options and what they do. -(fwiw, an example of suffixes I’m having trouble adapting to my wip are in the “simple list output” sample you uploaded in another post - specifically the lvl1 lvl2 lvl3 suffixes) I think I’m ok using the placeholders that are included in the help menu for things like document properties and pages/numbering things.
Perfect - “RemovePrivateDetails” Got it!
(Off to look up how to just eliminate the brackets from the output)
PCRE-Compliant Thank you!
(I’ll venture to guess that that dollar sign will be in my “replacement” field in the above-mentioned regex.)
It’s entirely up to you, what you have the compiler put around inline annotations. They can even be converted to margin notes for word processor formats (which is in fact the default behaviour), or turned into footnotes… I was just thinking that if you did want to keep a standard of using double-brackets for personal compiled copies, you could. If that isn’t something you want or need, then maybe leaving them default so they turn into ODT comments is best.
And yes, if you only want to remove the brackets, leaving the note behind as unmarked text, then this would work:
Replace: \[\[(.*?)\]\] With: $1
The parentheses captures everything inside of double bracket pairs, and the $1 prints what was captured. You may need to work around spacing issues, depending on how you typed this in. Simply removing the brackets may leave extra spaces around letters. If you do need to find spaces, \s is a general wildcard for whitespace characters. This would strip out extra spaces if you tend to type them [[ Like this ]] instead: \[\[\s(.*?)\s]]
The text find panel, Ctrl+F. Switch it to regex mode in the lower right area.
Are you saying to use Ctrl+F (choose regex) in the editor first (project search) to test the results of the regex before I open the compile window to enter the expression in compile?
Where can I find more info on prefixes and suffixes I can use with text in the editor, or formatting in compile?
Yup, that’s how I test regex that I intend to use in the compiler eventually. It’s just a lot easier to adjust the syntax and keep hitting the Find button until it works right, then test the replacement.
I’m not sure if there is a “one stop shop” for all things prefixes and suffixes, since it’s kind of a general purpose concept, in and of itself, used in more specific ways for different purposes and contexts throughout the compiler. It’s more one of those things where if you find yourself wanting to do something very specific, you learn about the kind of prefix or suffix that accomplishes that.
For example, you might want to put “Fig. <$n>:” in front of all the text you mark as a Caption style. That’s a nice easy way to number your captions in a linear way without having to type it in over and over. That would be set up in the style’s paragraph prefix field. Another example are those “Return to chapter” hyperlinks in the user manual, at the end of every major section. Those are inserted using a Section Layout suffix, with the option to insert it after all of the child items of binder item that triggered it. That is a very different thing from the caption, and the implementation is entirely different as well—but in a very vague way both are examples of prefixes and suffixes.
What sort of prefixes and/or suffixes would I use on inline annotations? I need a tutorial (or a manual page) on prefixes/suffixes I’ve also hit some stumbling blocks in the compiler with prefix/suffix settings. I need to start at the bottom - I am not (always) grasping what the purpose or meaning is of prefix/suffix combo’s or how to “read them” when they exist in samples. I need a good explanation of the general concept, expected syntax, and a list of possible options and what they do. -(fwiw, an example of suffixes I’m having trouble adapting to my wip are in the “simple list output” sample you uploaded in another post - specifically the lvl1 lvl2 lvl3 suffixes) I think I’m ok using the placeholders that are included in the help menu for things like document properties and pages/numbering things.
