I’m trying to $include a LaTeX table I’m keeping in another Scrivener text using the following syntax:
<$include:test>
In this, test is a Scrivener link pointing to a text file containing the table. The text file has a custom section type latex, which is associated in the compile settings with a section layout latex, which wraps the section in the following code to pass as raw source to MultiMarkdown:
Prefix:
[code]```{=latex}
[/code]
Suffix:
[code]
This section layout generally works fine if I include files directly in the compiler. With [code]
$include:test>
[/code] however, I noticed that the section style of the included file - in this case [i]latex[/i] of the file [i]test[/i] - gets ignored (Meanwhile paragraph level styles with the same prefix get passed correctly).
After some testing I found that removing the custom section type from the text file to be included, and wrapping the $include itself inside the MultiMarkdown tag for passing raw source seems to work:
[code]```{=latex}
<$include:test}>
```[/code]
To simplify this linking I tried to set-up a Regex replacement rule, which replaces [i]@inc test[/i] with the same code, so it searches for
[quote]
@inc ?([^\n]+)
[/quote]
and replaces it with
[quote]
```{=latex}
<$include: $1
[/quote]
To my suprise, this doesn’t work either and Scrivener creates the following output, in which $include does not get interpreted:
<$include:test>
$placeholders and passing as raw source work fine in other Regex replacements, and I’ve tried escaping all characters, so I don’t think it is my Regex code. I’m not sure if I’m doing something wrong here or if there is a bug or if this is a rare feature not implemented, but neither behavior seems expected, and I think both cases should work, based on the way I interpret the specifications.
For now, I’ve identified two workarounds:
First would be using MacOS text replacement, e.g. replacing @inc with [code]```{=latex}
<$include:}>
Second would be to assign a paragraph level style using the MultiMarkdown raw source tags as prefix and suffix.
Personally, I think I'll use the second option for now.
I’m sure someone more savvy than me will answer, but may I point out that this thread would be better located in the dedicated MultiMarkdown & LaTeX forum.
I’m not sure - the issue occurs in the context of LaTeX, but I suspect it is an inconsistency in the way Scrivener handles place holders (or I overinterpret the specification - either way it should be made consonstitent IMO).
But the issue seems to be to specific as the lack of responses seems to suggest, but thanks for responding anyways, and it is not urgent, as I managed to work around it myself.
The feature is designed to grab the text from a file and insert a copy of that text into the document where the $include tag is placed. It’s not designed to act as if the document that has the $include tag in it were split around the include tag, and then have that document replaced by a copy of the doc that $include points to.
It’s more a macro than a document placeholder.
If you wanted to, you could format the text of the document with a custom style, and then modify a copy of your compile setting to surround the paragraphs of that style with the LaTeX escape characters. I suggest making that style appear unique within Scrivener, so you’re sure all of the text is marked with it.
Yes, styles are the way to go here for this particular usage of the <$include> placeholder.
The reasoning behind that design decision is correctly identified by rdale. The idea is that one chunk of text could be inserted into different layout contexts depending upon its intended purpose. To provide a practical example: in the user manual project’s appendix section, each preference setting and menu command is broken out into separate items. Everything about how these two pieces of content are formatted is driven by section layouts. There is a “Menu Command” layout, and so on. In most cases they are formatted as a variations Markdown dictionary list (menu command also inserts the shortcut from custom metadata into the “title”, or definition term in this case).
However sometimes I want to take the text that explains a command or setting, and inject it into an entirely different context, such as a bullet list, tip box, or even a footnote. If the <$include> command pulled the whole section layout with it, it would break formatting and overall reduce the flexibility of the feature.
So that does mean that for bits of text that are intended to have a consistent format no matter where you insert them, you will need to use styles to achieve that effect. I can insert a tip box anywhere, because those are entirely style-driven.
As for their interaction with Replacements, there are a few blind spots you have to work around like that. Another one is conflicting styles placed on top of the placeholder, since the placeholder brings in its own style. In short, including text is meant to be fairly simply done, mainly because integrating it deeper into the various compile loops would get convoluted, very quickly.
I also understand the reasoning behind the way this feature is encoded, but maybe this should be clarified in the documentation in more detail - particulary around these ‘few blind spots’ you mention - May be a corner case but it took me hours to understand the behaviour and find a working solution,
Scrivener is a powerful piece of software, but sometimes I find that the specification and the limits of features are not always clear (To give another example off-topic - I’ve been looking into using Scrivener placeholders to insert project metdata on compile. Also there it took me kind some time to realize that it is not possible to insert project metadata, but only custom metdata specified for individual files and folders).
This is documented at the end of that section, under How Included Text Formatting Works, pg. 217. Let me know which part of this you found to be missing, as I’m pretty sure I covered all of the above and then some. It’s quite detailed in exactly what will happen.
Hmm, could you clarify what you mean by “project metadata”? To my mind that brings up placeholders like <$projecttitle> and <$author>. That aside, it isn’t the case that only custom metadata can be inserted. Just about everything that you can add to the Outliner as a column has a placeholder for it as well, and more besides. For example you can insert the <$title> of an item—usually you’d just use the Title checkbox in the Section Layout settings, but there may be times where you want more control over the layout. Maybe for some odd reason you need the title to fall after the text. All of these codes can be found in the Help ▸ List of All Placeholders… cheat sheet.
Now if by “project metadata” you mean, why can’t there be a <$label> or list of <$keywords> for the entire project or something—it’s true the entire project does not have an Inspector pane, only items in the binder can have these things. But that isn’t a complete roadblock:
Create a document somewhere, maybe at the very top of the binder above Draft, and call it “Project Metadata”.
Add stuff to it using the inspector.
Now whenever you want to refer to this global metadata, use the <$keywords> placeholder or whatever, select it in entirety, and create a document link pointing to the “Project Metadata” file.
If you do that a lot, consider keeping a list of pre-linked placeholders in a file somewhere, and drop it into the Project Bookmarks list for easy access.
