This is so simple, I’d be surprised if anyone who was interested in doing it hasn’t done it already. Nonetheless…
I sometimes want to extend MMD syntax a little bit in Scrivener. I’m compiling for LaTeX, so what I’m really doing is throwing in a little LaTeX. For fixed replacements, it’s easy, I just use a replacement. But since there’s no way to parameterize metadata or replacements (those would be on my wish list, frankly), I just make up arbitrary commands, e.g.
NewEnvironment([some text])
And then use the following two replacements
NewEnvironment([
[/code] gets replaced with [code]
<!--\NewEnvironment{
and
])
[/code]gets replaced with [code]
}-->
It would be AWESOME if I could refer to my document notes with some format similar to the Project Properties, with a syntax like <$docnotes>. Maybe I can, and don’t know it? I would then transform RedBox[(<$docnotes>)] into
See §23.14.1, “Advanced Replacements Usage” (pg. 333). But basically in brief:
Replace: ^$@^ With: \index{$@}
Will replace anything falling in between two caret symbols with the code in the replacement. So ^something^ would become \index{something} in the compiled copy.
Well, THAT’s cool, thanks! I’ve already got my export settings to transform my comments into comment boxes in the PDF LaTeX output, using the footnotes/comments setting compile section, but I totally missed the parameterized replacements. Dang.
Have I also missed any ability to refer to additional meta-data? The only ones I’m aware of are the Project Properties, like <$projecttitle>, etc. I would love to be able to have a similar ability to pull in other meta-data like Label, Status, custom meta-data, and especially document notes.
Oh yes, most of the meta-data is available for inclusion! For the complete listing check out the Help/Placeholder Tags List.... Read the notes for each section, as not all of them are applicable everywhere—some only work in the header/footer fields and such. Most can be used everywhere though. Meta-data is all in the Document Variables section. <$label> does as you would expect (even if you’ve renamed Label to something else in the interface that will still work). You can even call on custom meta-data, which can be very handy for this type of stuff. For example, if you wish to label sections differently from their literal titles, you could set up a custom meta-data field called “section_label”, and then add a section heading suffix to the compiler level settings like:
[<$custom:section_label>]
Leave the inside hashmarks option turned on, for a result like:
## Binder Title [customlabel] ##
Now you can cross ref to [customlabel][] even if Binder Title changes. This is what the user manual project does. Since menu labels and such frequently change, I often use hard-coded labels so my cross-references don’t get bent out of shape by MMD’s automatic title->label code. The only drawback with that method is that if you don’t give a label to everything you get empty brackets which MMD presumes to mean you don’t want a label at all. So if you don’t want that, you have to pipe the compiled file through sed or something to clean out the " [] #+" junk.
In fact, if you haven’t already, you might wish to download the .scriv project for the user manual. It’s an MMD project, and while it is still set up to use MMD2 tricks (special stuff goes through HTML -> XSLT), you might find some useful things to use in your own projects.
I don’t believe there is a placeholder for document notes, however. You can of course turn on document notes in the compile formatting settings and choose between top or bottom. Combined with clever usage of Separators and title suffix/prefix, you might be able to wrap them in environment code without anything in the editor—but honestly it might be better just to use a custom meta-data field for this type of thing. Not only can you call it as a token, you can also have more than one per section.
Excellent! I forgot to mention that inline annotations can be provided with custom delimiters, too. So use that to your advantage. See the Comments/Footnotes compile pane.