Placeholder Bug

[karl]

There seems to be a bug in Scrivener 3 on how many times you can use auto-numbering placeholders to cross-reference. It seems you can only reference twice before Scrivener treats the reference as plain text. Addition of more references results in a refusal to compile (the compiler seems to be stuck in a loop).

Here is the results using the example given in Scrivener.

Input
Figure <$n:figure>, Figure <$n:figure>, Please see figure <$n#figure>
Output
Figure 1, Figure 2, Please see figure 2

Input
Figure <$n:figure>, Figure <$n:figure>, Please see figure <$n#figure>, figure <$n#figure>, figure <$n#figure>
Output
Figure 1, Figure 2, Please see figure 2, figure 2, figure <$n#figure>

As can be seen, the compiled text has not replaced the third cross-reference placeholder, it seems to see it as plain text.

Input
Figure <$n:figure>, Figure <$n:figure>, Please see figure <$n#figure>, figure <$n#figure>, figure <$n#figure>, figure <$n#figure>
Output
Will not compile when trying to reference the figure four times.

[AmberV]

Are you still getting this behaviour in 3.0.1? I think this has been fixed, or at least I can no longer reproduce it using your tests.

[karl]

Are you still getting this behaviour in 3.0.1? I think this has been fixed, or at least I can no longer reproduce it using your tests.

Hi AmberV. No I'm not getting this behaviour but there is still a placeholder bug in 3.0.1. It seems that if you have two (or more) autonumber placeholders, then referencing one of them will cause the compiler to crash.

Will Compile
<$n:figure>
<$n#figure>

Will Compile
<$n:figure> <$n:table>

Will NOT Compile
<$n:figure> <$n:table>
<$n#figure>

Karl

[AmberV]

Hmm, I’m not getting that crash with a quick test:

1. Created a new blank project.
2. Copied and pasted your example text into the editor.
3. Compiled using default settings.

Print preview result:

Code: Select all

1 1
1


It might need additional compile settings, a specific file type, etc.

[karl]

Hmm, I’m not getting that crash with a quick test:

1. Created a new blank project.
2. Copied and pasted your example text into the editor.
3. Compiled using default settings.

Print preview result:

Code: Select all

1 1
1


It might need additional compile settings, a specific file type, etc.

Puzzling . Can I send you my sample project that won't compile?

[AmberV]

By all means. You can use the File/Back Up/Back Up To... command to create a zipped copy and attach it to a PM, or if that is too large, send it via email to our support address, and mention the forum thread URL in case someone else gets to it first. I’ll try to keep an eye out though since the post-holiday backlog is rather impressive.

[karl]

By all means. You can use the File/Back Up/Back Up To... command to create a zipped copy and attach it to a PM, or if that is too large, send it via email to our support address, and mention the forum thread URL in case someone else gets to it first. I’ll try to keep an eye out though since the post-holiday backlog is rather impressive.

I've sent a PM. Thank you.

[KB]

This should be fixed for 3.0.2, I believe, as I think this was sent to us via support, too, and I addressed it on Friday.
Thanks!

[karl]

This should be fixed for 3.0.2, I believe, as I think this was sent to us via support, too, and I addressed it on Friday.
Thanks!

Thanks Kieth.
Karl.

[karl]

Hi. I updated to v3.0.2 today. Unfortunately the placeholder bug is still not fixed (may be a different bug).

Instead of trying to give a complete explanation I have attached a project that reproduces the bug. But in summary, introducing two placeholders and referencing them works fine. When a third is introduced, the first placeholder to be referenced simply appears as text (i.e. <$ etc) not a number. When a fourth placeholder is introduced, the compiler seems to get stuck in a loop.

Thank you.

[KB]

Thanks for the sample project, that allowed me to see the bug straight away. To say the code that handles this is complicated is an understatement. Looking at the issue and logging different results in the code, I found that the search ranges were off for the reference tag replacements. I had a hunch about how the code could be changed to fix this, and rewrote the section that handles this part of the auto-numbering in about an hour, which worked nicely. But it then took another two hours to work out exactly why the original code wasn't working. (Obviously it's crucial to know *why* code isn't working to avoid similar mistakes in the future!)

So, this is fixed for 3.0.3.

All the best,
Keith

[karl]

Thanks for the sample project, that allowed me to see the bug straight away. To say the code that handles this is complicated is an understatement. Looking at the issue and logging different results in the code, I found that the search ranges were off for the reference tag replacements. I had a hunch about how the code could be changed to fix this, and rewrote the section that handles this part of the auto-numbering in about an hour, which worked nicely. But it then took another two hours to work out exactly why the original code wasn't working. (Obviously it's crucial to know *why* code isn't working to avoid similar mistakes in the future!)

So, this is fixed for 3.0.3.

All the best,
Keith

Thanks Keith. I worked as a software engineer for many years myself (until a few years ago) so I know bug hunts can take a long time. Well done for doing it in a few hours!

karl.