Unexpected chapter numbers when using placeholders

Scrivener Scrivener for macOS
, ,
1

Hello,

I am using placeholders, such as “this shall be further discussed in part 1.2.1”.

I did not include any <$hn> in the titles of my parts/chapters/sections because it is already present in compile.
I just write “this shall be further discussed in part <$hn>” and link the <$hn> with the given section by sliding the title of the section on the selected <$hn>.

This seems to work fine when I compile.

When I compile only part of the draft and some references are to sections that are not compiled, it reads “part ??”, which makes sense, I suppose, since the part is not there.

On the other hand, I get things such as “part 1.1.6.1.6.4” when it should read “part 1.6.4”, and I have no idea where the additional “1.1.6” is coming from.

Does anyone have any idea what might cause this?

I have an additional question, also: is it possible to put placeholders in footnotes?
I have tried to do so, but it does not seem to function.
Is there a workaround? It is quite common to write things like “see part 1.2.” in a footnote, so that would be very convenient.

2

This, perhaps ?

image

1 Like
3

Thank you.

Actually, I tested adding it to 2 or 3 titles, but since I have set my section layouts in compile to “decimal outline items”, when I go to “title options” in “section layouts”, the title prefix already reads <$hn>.

…so when I added it in the titles, it displayed twice for these sections.

I tried deleting it from the titles, and it seems to work well.

Do you think that I should do the opposite, that is start each one of my part/chapter/section titles with <$hn> and delete it from the title prefix in Compile?

I have to admit that the difference between the two is way too subtle for me.

4

I would say that if it works now… leave it as it is.

1 Like
5

Yes, I figured that I would first test it this way, instead of renaming all my sections. If I really need to rename them, though, it is not going to take that long.

Well, it works… except when it doesn’t xD

I wonder if that anomaly would disappear if I did it differently. That’s why I thought I would ask here. I usually just do trial and error, but when things don’t work as expected, I prefer to ask more informed users on what is the most “orthodox” way of doing it, since I do not understand anything about the coding that goes on behind it :wink:

6

Using placeholders like that is kind of what one could call “the basic form” of their potential usage.
For more advanced possibilities, angle your curiosity toward LaTex.
But this I can’t help with, though, as I’ve never used it, nor even remotely investigated in that direction.

1 Like
7

Based on that description, I do not think you are doing anything “wrong”, but are running into a known bug. I’ve checked and it is still listed as an unfixed issue, but I don’t believe it has ever been talked of on the forum before. The person that noticed it wrote in to us directly.

There are unfortunate limitations in the Mac version with regards to putting these kinds of internal links inside of inspector footnotes. If you need a link in a footnote that works properly for stuff like this, then use an inline footnote instead (you can select the text around the footnote and use Edit ▸ Transformations ▸ Convert Inspector Footnotes to Inline Footnotes for ones that are already written).

2 Likes
8

Thank you very much for your answer.
It is nice to know that I am not doing anything “wrong”, at least.

Do you know if there a work around?
I would suppose that there must be some way of referring to chapters before they have their definite numbering. If I need to investigte LaTeX for 2 or 3 days in order to do it, it is probably worth it, even though I was hoping to avoid too much technicality by using Scrivener, which is really a powerful tool with a great interface.

Concerning linking in a footnote, the solution you have given me seems perfect. I can definitely work with that :slight_smile:

Am I right to say that, when I compile the whole thing, the fact that it is an inline footnote will not affect anything, I mean it will be treated the same way as if it were just another linked footnote?

9

I suppose it is a matter of opinion, for I find the “rich text” way of doing things to be often way more complicated than using LaTeX, and it is a common misunderstanding that one must use the former with Scrivener, or that such is the intended way to use it (we even have a project template for LaTeX projects), or that those that do not are “missing out” on something special that the software does. I can’t think of much actually, as almost all of its feature set to can be tooled toward plain-text syntax creation (and the parts that can’t aren’t terribly interesting by themselves, like raw direct formatting without styles backing them up, it’s just bad form to work that way anyway).

That said, if one doesn’t know much about LaTeX, I wouldn’t expect a two or three day detour to solve your problems other than make a huge snarl of new ones! I’d say it’s one of those things where if you do know it, Scrivener becomes alot easier to use, and you can spend more of your time writing productively rather than messing with settings and such trying to—very weakly and sometimes in counter-productive ways—somewhat mimic what you can do with LaTeX. All of that powerful stuff with a great interface becomes aimed at pure text production, in other words. I wouldn’t create a large-scale .tex file without Scrivener, nor a Markdown file for that matter!

Do you know if there a work around?

Probably the only real one amps up the complexity by a large amount: using the placeholder system to create your own numbering streams rather than using the <$hn> counter. You’d be looking at something more like:

<$n#chap:<$level1_title_no_spaces>>.<$n#sec:<$level2_title_no_spaces>>.<$n:subsec:<$title_no_space>>

And different forms depending on whether you are referencing or incrementing counters, of course, and more of these iterations the deeper the numbering goes.

At that rate, one would certainly not be typing these in by hand, and would have to rig up their project with Replacements to generate such codes (and yes, Replacements, if they replace the whole of the placeholder-for-a-placeholder, will convey a link through to the final form).

Am I right to say that, when I compile the whole thing, the fact that it is an inline footnote will not affect anything, I mean it will be treated the same way as if it were just another linked footnote?

You’d have to go out of your way to make them act differently. There is a setting to treat one as endnotes and the other as footnotes, which can come in handy for those that need such a thing. It’s not a default though.

1 Like
10

Thank you for this long explanation.

The last part is very clear: since the default is that inline footnotes behave like linked footnotes, I will use inline when I need to insert an internal reference to another part/chapter/section, as you suggested.

Since I do not know anything about LaTeX, I could probably use the line of code you kindly wrote for me.
If I understand well, what you suggest is I could leave a placeholder for the moment (but not the <$hn> counter), and in Compile > replacement, replace the counter with <$n#chap:<$level1_title_no_spaces>>.<$n#sec:<$level2_title_no_spaces>>.<$n:subsec:<$title_no_space>>

Is that right?

One sentence I did not understand is:

“Referencing” counters is what I was already doing, I supposed, but “incrementing” counters, I have no idea what you mean.

Is it how you refer to having a different line of code depending on the “level” I am referring to (part/chapter/section…) ?

If that is the case, then I suppose that what I write in the code has to correspond with how I defined my chapters… For example, I need to first define the first level as “part”, the second level as “chapter”, then “subchapter”, “section” and “subsection”, THEN insert this in the code so it would look something like that for a subsection:
<$n#part:<$level1_title_no_spaces>>.<$n#chapter:<$level2_title_no_spaces>>.<$n:subchapter:<$title_no_space>>.<$n:section:<$title_no_space>>.<$n:subsection:<$title_no_space>>

For a section, the counter would be one level shorter, and even shorter for a subchapter, and so on.

I hope I have understood things right. If so, it seems doable.
While writing, this means I need to insert a different counter depending on which level I am referring to so that I can replace 5 different formulas in “replacement” in Compile.

I imagine the in-text formulas to be replaced could simply be , , , and .

Do I have everything right?
I hope so. My field is translation studies and musicology, not programming, so I hope I don’t have it all wrong xD
I have fiddled a little bit with the CSL in Zotero to tweak citation styles, but that’s about my only experience in coding.

I was hoping that the <$hn> counter would do the trick.
All this is a bit more complicated than I expected, but I still think it is worth it, still much better than waiting until I have 400 pages and going through all the references afterwards. Initially, that is what I had thought of doing, so I had written “part??” each time… :-/

11

I could probably use the line of code you kindly wrote for me.
If I understand well, what you suggest is I could leave a placeholder for the moment…

Honestly this is my preference no matter, because I am a firm believer in keeping formatting decisions out of the data—and numbering styles are a form of formatting. It’s one reason I use Markdown, because for me a cross-ref looks like this while writing, [Name of Binder Item], and that’s it. I’m not thinking about what that looks like, just what the intent is. What it looks like comes later after compiling.

So using a Replacement (which you can read all about in §23.4.4, Project Replacements, and also §24.14) can give you a similar level of abstraction that Markdown-based writing methods do: where writing is much simpler and you aren’t having to dwell on and perfect implementation details while writing.

You can type in, let’s say, #[namewithoutspaces], and link it like you would a placeholder, and have it turn into something more like that long code example (which as you note, isn’t meant work out of the box).

I was mainly showing that you can make your own custom <$hn> marker and do whatever you want with it. You can get past the bug in this way… but another thing to consider is that if you use replacements instead of literal placeholders in your text, you may be able to just in the end have the replacements output <$hn>, if the bug gets fixed by the time you compile.

I.e. maybe don’t worry about reinventing what that placeholder does until you need it, if the bug isn’t fixed when you need it.

“Referencing” counters is what I was already doing, I supposed, but “incrementing” counters, I have no idea what you mean.

That makes sense, since you’ve been using a placeholder that isn’t a typical incrementing numbering tool but one that simply reports the position of where it is used, or where it links to. There is a difference though between these:

<$n:chapter:chapterone>
<$n#chapter:chapterone>

The first line will increment the $n counter the first time that specific named instance (‘chapterone’) is used. The second will not. It is a pure reference, and thus can be used to refer to chapter one before chapter one occurs in the text. So all around it is safer to use the second line for references no matter where they are, in case things get moved around.

So that first punctuation mark after the counter type is the key, and that should help explain why some of my example had those, while the last part had a colon. For an actual cross-ref to that section we’d want hashes across the board.

All this is a bit more complicated than I expected, but I still think it is worth it, still much better than waiting until I have 400 pages and going through all the references afterwards. Initially, that is what I had thought of doing, so I had written “part??” each time… :-/

True, though it really depends on what you need and how long you intend the output document itself to be “alive” for. Scrivener’s approach is kind of… “dumb” let’s say, in the sense that the result is exactly like having gone through and typed in the numbers by hand. If this document needs to live on after you compile it, for years maybe, and survive multiple rounds of revision and editing—maybe manually typed in chapter numbers and such is a bad idea, for all of the obvious reasons we would want to avoid doing that in Scrivener too.

It might be worth it, in that case, to deferring all of that to the stylesheet and marking down where actual cross-ref fields should be inserted as opposed to text that statically says, “1.2.3 King of the Hill”. It will mean more work when you’re done with Scrivener for this particular project, but it will mean a document that isn’t static and dependent upon Scrivener after that point.

This isn’t a choice you have to make up front though if you make use of the concept of abstraction. If you aren’t going to use a writing method that has that concept built in, like Markdown, then Replacements are the key to keeping your work flexible, where the implementation is something the compiler does to the source.

1 Like
12

Thank you.

I have to admit I had to read the whole thing three times and I still haven’t understood everything xD

… but to sum up, I am probably better off continuing with <$hn> for the moment and I cross my fingers for the bug to be resolved before the end of June, when I will need to compile the whole thing.

If it is not solved by then, I will have to use a replacement options, but no need to read too much about this right now (I have read §23.4.4 and 24.14; the former is quite clear, the second much less).

Just to make sure: in the case I finally need to use replacements, will it not be a problem if I used <$hn> everywhere, even if some of the cross-refs are to chapters and others to sections, for example?

13

Sure, it’s tossing the dice as to whether the bug will be fixed by then or not (I would hope so though). A replacement that turns into that would be safer, is what I was getting at.

1 Like
14

Ah! OK. Sorry, I think I had misunderstood.
What you mean is I could use a tag such as what you mentioned before, for example ‘[Number of Binder Item]’, link THAT to the target binder item, and replace it with <$hn> in Compile?

If the bug gets fixed by then, it will all perfectly, and if it isn’t, I guess I will just have to do everything by hand.

I did not answer you about the time it needed to be “alive”. It is a PhD thesis, so essentially, I will need to compile it to a .pdf and print it. In the meantime, I export it as .docx for my supervisor to read/revise.

… and I intend to publish it afterwards, which will probably require some modifications, but it will be much easier to reoriganise things if I have done the work correctly beforehand (cross-ref…).

15

What you mean is I could use a tag such as what you mentioned before, for example ‘[Number of Binder Item]’, link THAT to the target binder item, and replace it with <$hn> in Compile?

Exactly, it can be simple like that if it turns out this is all you need. That way, if hn doesn’t work, you can have the replacement create something else for you, maybe more complex—or maybe even just a marker that you can search for in Word and turn into a field if you prefer to go that route. It leaves your options open with a simple switch to flip in the compiler, rather than fixing hundreds of individual bits of text.

Sample replacement...

If you copy and paste this code into your compile setting’s Replacement table, it should do just that:

<Replacements>
<Replacement RegEx="Yes">
    <Replace><![CDATA[#\[(.+?)\]]]></Replace>
    <With><![CDATA[<$hn>]]></With>
</Replacement>
</Replacements>

At any rate, I’ve bumped the ticket on this as something worth fixing rather than leaving somewhere in the to-do list, so I should think a fix would be sooner than later.

16

Thank you very much for the ticket. It would be sooo helpful!

Thank you for the code, also.

I am not sure I understand, though. I thought I would just write ‘[Number of Binder Item]’ in the first column and ‘<$hn>’ in the second column, and that’s that.

… or is the code you have just sent me for the case the bug is NOT repaired?

In that case, if I copy/paste your code in the Replacement table, what am I supposed to write inside my text afterwards, whenever I want to make a cross-ref? Just ‘[Number of Binder Item]’ ?

17

All right, I’ve just received word that linked <$hn> placeholders will be fixed in the next update, so honestly your best bet is to just go with that as you have been. It won’t work right for now, but it should by June.

2 Likes
18

Wonderful news! Thank you very much for everything.

Do you know if I need to look for this update? Or am I going to receive a notification to update?

19

image

1 Like
20

Thank you. Just checked. It was already set by default, apparently.

Have a nice day.

1 Like