Help with linking placeholders

The less you do for yourself, the less you understand in the long run.

Hi Justin
I am starting year 9 of my PhD, with my full draft sent for copy edit checking yesterday. In 2016 I moved from Word to Scrivener (Windows Scrivener v. 1.X and now v. 3.x). I compile to Word for sharing with my supervisors. If I had not had a good idea on the thesis structure when I started using Scrivener, I would have done things differently. However, working with the Beta migration and staying connected via this community is what made the difference to what I understand today and how I adapt some key things. Sometimes I break something and it is through this forum or searches elsewhere that I learn some more and solve the problem. I am using Endnote with no problems of late and ProWritingAid, to good effect. I have workarounds for tables, styles that work well with Word and auto numbering throughout. I would say that the template I started with gave me false expectations.
I agree with @drmajorbob - the sooner the “hands on” approach is adopted, the sooner we begin to access the true power of Scrivener. I am looking forward to going to a next level with Scrivener, once I finally push the submit button on this current project.
All the best with your project.

1 Like

Yes, you can avoid any kind of workarounds like this by making use of Replacements. A key thing to note is that Replacements run more than once. They run fairly early on so that you can create complex placeholders (as explored in the linked howto), but they also run a bit later on, so that we can do stuff to any text generated by placeholders.

Therefore we need to create a number that looks unique based on the text around it, and then delete any numbers that match that pattern, leaving the other numbers in place. For example, this would go into the title suffix:


Upon compiling, that would result in, “1. First Chapter~~1”. Now we have a unique looking number that we can be sure to destroy. And regular expressions will help us make a statement such as “any digit following two tildes”—something otherwise difficult with typical search and replace matching.

In the Format’s Replacements pane, add a RegEx replacement for ~~\d+ and replace it with nothing. Or copy and paste the following into the replacements table:

<Replacement RegEx="Yes">

This is inspiring. With such Replacements, assuming that we use <$hn> for chapter/section numbering, can we do this for table numbering:

  • Use Table <$hn>.<$n:table:Identifier> Caption for table caption
  • Use Table <$hn#>.<$n#table:Identifier> to refer to the table
  • Add a Replacements of /(^\d*)(.*)(\.\d*$)/ \1\3 to remove the trailing section numbers. (Essentially we are looking for something like <$hn_level1>.)

This would spare the additional <$n:chapter:<$title_no_spaces>>. But I don’t understand where the last Replacement can be placed. If it works, an example project is greatly appreciated.

Overall I would say <$hn> is better for simple cases. If you need complicated references, essentially creating these on your own with the leveln placeholders and such is probably better. But if you can get something working with it, it does make things a little cleaner than manually building what that placeholder does automatically.

This would spare the additional <$n:chapter:<$title_no_spaces>>. But I don’t understand where the last Replacement can be placed. If it works, an example project is greatly appreciated.

There are two places to put Replacements:

  • In Compile overview, in a tab on the right side, is a good place for stuff that only pertains to one project.
  • If you double-click on the Format you are using in the left sidebar, you’ll find a Replacements pane in the Format Designer window. This place is ideal of style decisions.

Ultimately though, it’s up to you. My own inclination would be to class all of the above under the Format. How things are numbered are part of the overall look and feel of the document, not the data of the project. Even if this project will never look another way, maybe all of this is how you’d like your next project to work too, and being able to just apply this Format to it as well and have it all work.

That’s why I like to use abstract tokens in the editor which are turned into specific implementations by the format. !fig(something) doesn’t say anything about the numbering, only that we may want numbering. The Format then decides how that works—or it just deletes the placeholder entirely if that approach isn’t meant to have numbering.

This works with chapter titles, except in the TOC. See attached screenshots. Please help again.


I think for how you are using the suffix field on your titles, you will probably never want them appended to hyperlinks (which includes the ToC). So go into your compile Format, and in the Document Title Links option pane, and enable Do not include title suffixes in updated links.

I have Do not include title suffixes in updated links checked but ~~~1~~~ still shows up in the .md file from Compile to MultiMarkdown.

Also, replacement (in Compile) ~~~\d+~~~ to '' does not work. Though replacement ~~~<$n:chapter:<$level1_title_no_spaces>>~~~ to '' works, but then it cripples the table numbers.

So we still don’t have a fully working solution…

Okay I was confused by your use case. I guess my main question for you is why you are using Scrivener’s basic ToC and auto-numbering features if you are using MultiMarkdown? I’ve never needed these things since I can easily get that stuff in a much better format on output. Scrivener’s stuff for this is rather brute force and not the best practices (static numbering, static text for the ToC instead of actual captions and stylesheet driven ToCs).

That aside, I think you could maybe put what you’re doing in the Prefix tab of Section Layouts rather than the title suffix. I don’t see why it would need to be there, specifically.

With the regex replacement not working, hmm, yeah it looks like the Mac is running that process too early. I tested that solution out on Windows, where it works fine. I’ll write that up and see if is something that can be changed.

I think ultimately though, I would reiterate what I said above: this is one of the side-effects of trying to use <$hn> in a more complex environment. If you actually need access to the individual components that <$hn> generates, then it is better to rebuild what that macro does with actual chapter numbering and such.