Tracking variable during compile?

A very basic question for those who use Scrivener+LaTeX and compile using TexShop.

I’d like to determine when and where in the code the numerical value of footnote changes. I 've developed a system where with a few lines of code, I can switch back-and-forth between footnotes and endnotes on a chapter/section/subsection basis through out my Scrivener project.

However, there is one single spot where footnote is incremented by one, as if a footnote exists where it does not. I can use a kludge to force footnote to a particular value using \setcounter{footnote}{...}, but that won’t tell me how or where the footnote is being incremented.

My question is this: When I compile using TexShop, is there a way to flag when the value of a variable changes? It would be ideal if it were possible to halt compilation at the offending line of code when the numerical value of a variable, in this case footnote, changes, or if the offending line of code could be flagged and recorded in a file with the appropriate line of code (or at least the line number) when the numerical value of the footnote changes.

Is this at all possible?

Thanks for reading,
scrive
:thinking:

To be clear, the footnote numbering in your set up would be being done by LaTeX’s compiler, not Scrivener’s compile. I don’t know any automagic way to chase down the increment associated with the \fn{}.

You need to open your output .tex file and walk though the source code from the point of the last right-numbered footnote to the place where the next footnote is appearing (with fn number one too high). Since I think you use plenty of footnotes, the amount of source to look through is maybe not too much?

Personally, I would search in that span of text for an instance of \fn{…} that does not show in the pdf output. It will likely be wrapped inside some other command that is suppressing its output or otherwise hiding that footnote. BUT the function that is wrapped around the \fn{} call is not treating its argument as text-literal, it is instead allowing the code inside to resolve (including the \fn call) before it does whatever it does. The result is that the footnote command gets processed as usual (thereby incrementing the footnote number) before that command wrapped around it goes on to suppress its appearance or otherwise screws it up so it does not appear.

1 Like

Hi gr,

Thank you so much for your response. The issue raises some interesting issues regarding the behavior of variables within the LaTeX, and I suspect other, compilers.

From my now distant experience dealing with computer code and programs, I remember how in some instances, many programming languages allowing for breakpoints in the code. Such breakpoints allow for a suspension of the running of the particular program where or whenever a set value changes.

In such a case, the program is haulted, temporarily or permanently depending on the language, allowing for inspection of the code to allow for inspection of the appropriate code.

Are you aware of any such breakpoint capability that exists within the LaTeX compiler?

Thank you again for your comment and feedback.

Sincerely,
scrive
:thinking:

Some of this is quite old, but may still apply:

I know several coding languages, but I honestly find LaTeX internals horribly convoluted and I’d seriously question trying to peer too deeply inside the box. However at least LuaLaTeX uses an excellent language which does have full debugger[1] available (the free Zerobrane: https://studio.zerobrane.com), perhaps that would be the most viable route into the belly of the beast!?


[1] I use this to debug Lua plugins for Pandoc, you can see the tricks here: lua-filters/lua-debug-example at master · pandoc/lua-filters · GitHub

1 Like

There is no need to go down the rabbit hole on this, scrive. The only thing that could be incrementing the footnote count is a footnote call, but it is easy to find footnote calls using regular text Search.

You just need to search forward in the text from the last good footnote call to find the next \fn call (that does not appear in the output) and this will be your culprit. You could cut out that portion temporarily and generate the pdf output again to confirm that you had found the troublemaker. Or, alternatively, define a new command called dufn that does nothing, and change the suspect \fn to \dufn and recompile pdf.

1 Like

Hi gr,

I was able to decipher the order of execution in the Prefix section of the Section Layouts using text statements to guide me along the path of execution, of which I had little understanding or knowledge.

Once I understood the order of execution, I was able to adjust the code order to obtain the desired effect.

Due to my extensive use of images, graphs, tables, lengthy quotations, et al. I’ve developed an unconventional arrangement whereby with a few well placed lines of code, I can switch between footnotes and endnotes by chapter, section or subsection.

My guess is the arrangement is not ‘according to Hoyle’, but at this point it serves me as I develop my story.

Thank you for your thoughts,
scrive
:thinking:

Glad you got it sorted.

1 Like

Hi nontroppo,

Thank you for the tips … my guess is at some point I’ll need to look into Lua/Pandoc… it is good to know that Lua ‘uses an excellent language’ and has a ‘full debugger’ for if/when I decide to make the leap.

Again, thank you for the recommendation,
scrive
:thinking:

P.S. I wonder what plans, if any, Scrivener may have for Lua/Pandoc within Scrivener …I’m assuming for the time being the LaTeX interface will be retained going forward … any soundings that that direction may change?

Only L&L know for sure; but I suspect the fundamental styles + text-based compiler option, which ultimately LaTeX and Markdown among others depend will remain, given that the User manual for Scrivener itself depends on it :slight_smile:

The question is if Scrivener would integrate any more tools directly? I think if Pandoc could be packaged to be smaller, they should swap MMD for Pandoc. That would get Scrivener the ability to generate academic bibliographies, along with a huge increase in possible compile format outputs, plus the ability to import a huge range of different documents retaining structure: Scrivener would simply implement one AST⇨Binder translator and suddenly be able to import >30 new document formats! And it could make use of compile templates, and use Lua for more complex compile customisation; all-in-one…

1 Like

The size of the Pandoc package is a real issue, and one of the main reasons why it isn’t integrated already. Of course, that large size is part of how it does everything it does.

1 Like

Indeed, like everything in life, you end up trading one thing against another :upside_down_face:

Note that compressed, IIRC Pandoc can be reduced to <20MB, which IMO is a fair trade-off for the large set of features it could add to Scrivener, but that is a trade-off only L&L can decide…

1 Like