Hello. I have a certain string of characters peppered throughout my project that I may or may not want to be in the final draft. The string is “( \cdot )”. I would love to be able to find all instances of this string and then make them all inline annotations. Then I’d like the ability to find them all again and then remove the inline annotation designation. Is this possible?
Thanks!
(Alternatively, I wonder if @nontroppo or @bernardo_vasconcelos knows how to wrap a string in such a way that Pandoc will totally ignore it. Then I could find the string and replace it with the wrapped version, and vice versa…)
Yes. Easy (exept for the “all” part – this is one at a time). Find next and
It is the same to remove it.
. . . . . . . . . .
You want them as inline annotation so they can be easily optioned out of the compiled output ?
If so, why not use a character attributes style instead? (can be opted out, as set in the compile format – you could even make yourself two categories : “for sure” and “maybe”. – As many as you want, in fact.)
Same result, only better. Especially if you want the instances you’ll leave in to compile as normal text.
. . . . . . .
You could even just write your ( \cdot ) as *( \cdot ) when you don’t want it to compile, and have your compile format’s replacements remove *( \cdot ) from the output.
( * or whatever other symbol you’d like if it messes up markdown. I just went for * without thinking much about it. Say %( \cdot ) ) ← This you could do them all at once, using Find / Project Replace. And you could still make yourself categories, using (manual input) different prefixes/symbols.
Thanks, Vincent. I use inline annotations a lot, so I do know how to use them in a one-at-a-time way. But yes, I was looking for a “select-all-then-make/undo-inline-annotation” option.
I hadn’t thought about using the character attributes style approach. I’ll explore that.
And your final suggestion should work too. Thank you, I appreciate it!
Might be talking through my hat, but I don’t think it can be done. (Perhaps using a third party app + a sync folder ??)
Or the Mac equivalent of AutoHotKey. Automate find next - inline annotation, repeat over and over – you’d stare at the screen to stop it before it starts back from the top and undoes what it just did. ??
Definitely seems like an option that Scrivener should have. Cough, cough, @AmberV.
But I just used your find"( \cdot )" and replace with “*( \cdot )” and then strip out upon compile with replacements, and it worked like a charm. Thanks!
If it is an “all of them or none” thing, I don’t think it is worth going through the Project Replace operation. Might as well simply properly check/uncheck your compile format’s replace-for-nothing whenever you compile.
I had the * prefix in mind for if you want some to compile and some not.
It seems @Vincent_Vincent did a great job with a search-replace solution, but for completeness based on your additional query:
Pandoc has a few ways to remove text. The most complex but flexible is a Lua filter, but there are simpler alternatives:
Raw attribute extension – you can make any part of your text specific to an output format, for example [note: replace ’ with actual ` backticks] 'some text'{=html} would only be seen in html output, but disappear in any other export. We can take advantage of this by doing 'some text'{=comment} – there is no comment format so this text is removed for every export. This can be inline or block.
Command-line option --strip-comments removes !<-- HTML comments --> so you can markup text with HTML comment syntax and use that command-line option to strip them out before conversion.
Here is an example:
▶︎ pandoc -t latex --strip-comments
# Title
Text here. `A comment here`{=comment}
More text. <!-- HTML comment --> More text. <!--- three hyphen comment --->
[CTRL+D]
\section{Title}\label{title}
Text here.
More text. More text.
▶︎ pandoc -t html --strip-comments
# Title
Text here. `A comment here`{=comment}
More text. <!-- HTML comment --> More text. <!--- three hyphen comment --->
[CTRL+D]
<h1 id="title">Title</h1>
<p>Text here. </p>
<p>More text. More text. </p>
There are probably some other tricks. If you use inline styles then any of these pandoc markup solutions become trivial with the style compiler, but could also be amenable to search-replace…
NOTE: you can test Pandoc on the command line like I do above, enter a Pandoc command but don’t specify an input file, so pandoc then waits for input from the terminal, you paste in some markdown then press CTRLD to get the output.
New question: Is there any way to protect a give string of characters from being subject to a project-level replacement that would otherwise change it upon compile?
UPDATE: I immediately thought of a solution that works if you’re using Pandoc to compile: just insert a dummy label (e.g. “\label{ignore}” in the middle of the string. It will be ignored by Pandoc, but it’ll prevent Scrivener from applying the replacement.
