Project replacement expanding to <$include:…> prints <$include:…> statement

User avatar
nostodnayr
Posts: 14
Joined: Sun Sep 09, 2018 12:27 am
Platform: Mac
Contact:

Sun Nov 04, 2018 7:55 am Post

A project text replacement (and it seems format-specific ones, too) that references an <$include:Text> placeholder, upon compiling, only outputs the raw placeholder, not its referenced text.

Scrivener 3.0.9 r9414
(Apologies if this is a technical limitation present in previous versions; I have only used 3.0.1 previously and experienced a corrected <$include> bug in that build.)

Steps:
1. Create a two texts: one inside the Draft ('test'), the other outside the Draft ('marker text')
2. Add some text to 'marker text'. Add text to 'test' but end it with !m on a blank line by itself
3. Open Compile screen and add a project replacement for !m which expands into <$include:marker text> (regex, case sensitive, whole word: all disabled)
4. Compile to PDF

Expected Result:
Final document includes the text written in both 'test' and 'marker text'.

Actual Result:
Final document includes the text in 'test' and <$include:marker text>.

User avatar
KB
Site Admin
Posts: 20729
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Sun Nov 04, 2018 3:01 pm Post

<$include> and other tags are themselves types of replacements, so you cannot rely on them being done in any particular order. The text is first built (compiled) and <$include> tags replaced, and then replacements are run on the built text. So what you are seeing is expected behaviour.
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

User avatar
nostodnayr
Posts: 14
Joined: Sun Sep 09, 2018 12:27 am
Platform: Mac
Contact:

Mon Nov 05, 2018 3:06 am Post

KB wrote:<$include> and other tags are themselves types of replacements, so you cannot rely on them being done in any particular order. The text is first built (compiled) and <$include> tags replaced, and then replacements are run on the built text. So what you are seeing is expected behaviour.


Thank you for clearing that up. I'll find a workaround for what I'm trying to do.