A flexible Compile screen

One of the many blessings that Scrivener not only allows but promotes, is a structured flexibility that, by design, can lead a writer to challenge such a flexibility that Scrivener provides, turned limitation, to be expanded.

I experienced such a flexibility, turned limitation, with my own unique approach to Scrivener Styles that I discussed here some time ago.

It appears I’ve bumped against another flexibility, turned limitation, with the Scrivener Compile screen. The existing flexibility to select/deselect the chapters, sections, subsections, etc. to be included in the compile has become essential for this author.

Such flexibility to Compile has spawned a wishlist item from this Scrivener/LaTeX author for a possible extension to the existing flexibility. Such an extension would allow an additional degree of freedom in how we may quickly select/deselect the chapters, sections, subsections, etc. to be included in the Scrivener Compile.

In my case, the wish list for additional flexibility arose from a particular conundrum that I faced on the LaTeX side of my Scrivener/LaTeX community of code. With literally several hundred chapters, sections, and subsections in my project, it would help immensely if I could easily and rapidly select/deselect entire groups within the list of Binder items to compile, or not compile.

Given the rather limited bevy of Scrivener writers who use Scrivener with LaTeX, it is understandable that interest in the wishlist item may be limited or non-existent.

The wishlist idea for the Scrivener compile screen would consist of two parts.

  • The first part would be to replace the binary checkmark selection alongside each Binder item on the Compile selection screen with a user-definable drop-down list. Such a drop-down selection list would allow the writer to group the Binder items on the Compile selection screen into categories of Compile items, which would then tie into the second part.

  • The second part would be to create a separate (perhaps popup) screen that displays one line for each item in the same user-selectable list of items described in the first part, with a checkbox alongside each item in the list. A checkmark alongside an item in the second part would indicate that that particular user-selectable group of items should be included in the Scrivener Compile.

The wishlist item arose out of a need to diagnose a condition that occurs when typesetting a post-Scrivener LaTeX project file: a non-zero exit code. This is clearly NOT a Scrivener issue, but if the wishlist item I described were available, diagnosing such a non-zero exit code could be addressed in an order of magnitude less time than without.

Although my wishlist suggestion may, at an initial glance, may appear to have limited utility for the average non-LaTeX Scrivener writer, there may be some other utility not documented herein for such writers.

Thanks for reading,

It sounds to me like the existing Filter system for determining what gets compiled already serves the purpose you have identified.

You can set up ad hoc or systemic Collections of binder items and then use the Filter option on the right-hand of the compile screen to quickly choose which group of docs you want to compile.

It seems like this facility could have been leveraged effectively in the scenario you mentioned, and is functionally (though not UI-ally) what you asked for.


Thank you for mentioning the existing, and very powerful, filter capability that already exists. The existing compile filter can certainly be adapted as I attempt to find what I am looking for.

The elusive non-zero exit code is something that has plagued my LaTeX project for years, and my wishlist item was an attempt to resolve the (non-Scrivener) issue longer term. The non-zero exit code complicates the use of the arara package when typesetting the LaTeX code as it halts continued execution of the arara directives the moment the non-zero exit code appears.

I’ll have to research how best I might adapt the existing compile filter to help me search for what is causing that elusive non-zero exit code. This will take some time to set up, but at least it is something I can use now.

A bird in the hand …

Thank you,

P.S. If anyone has any thoughts as to how I might otherwise approach the issue, I’m all ears …

If LaTeX previously handled the file correctly and now does not, then the thing you need to know is what changed. Abundant tools for comparing plain text files exist.

1 Like

Yes … I do use a text ‘change checker’ of sorts … I find the MacOS CompareMerge2.app to be perfect for the task.

I wish I could use the CompareMerge2.app in this instance, but I wasn’t even aware of that elusive non-zero exit code condition until fairly recently. Oh, if I only knew then back then what I know now!

Yes, the condition has plagued my LaTeX project for years, but I didn’t know what I was looking at. Although I keep dozens and dozens of backup files, unfortunately, those backups don’t go back to when that elusive non-zero exit code started to happen.

But even if I had backups from that far back, so much has changed that using the CompareMerge2.app would not be enough to allow me to separate the wheat from the chaff.

So I’m left with a classic optimization problem of how best to winnow down the 25K+ lines of code to find that missing } or { or whatever it is that is causing that elusive non-zero exit code condition !

But, thanks for the suggestion. It’s the best one I’ve had so far!


P.S. To be clear, this is NOT a Scrivener issue, just a challenge when typesetting LaTeX after Scrivener. But even having to deal with such a challenge (for those who are wondering), LaTeX is well worth it. Now, back to those Collections …

If one may suppose that your LaTeX bracket pairs do not (are not meant to) span multiple documents, then it seems like tracking down the problem should just be a matter of using a collection to cut out chunks of the middle docs from compile until you winnow it down to the culprit doc.

Unfortunately, it may be that the bracket pairing failure is not in your text at all. Knowing something of the size and history of your project, I know that you have a great enthusiasm for what packages can do for you, and you are invoking many, many of them. And for this reason the failure may be happening off stage: either within one of those packages itself or owing to two packages not playing nice together – where one package does something to what you feed it that then messes up what the next package does with that result.

((I haven’t thought too hard about this, so take with a grain of salt: Just making a doc with a close bracket in it, and placing it midway in the binder If you have a bracket pairing problem, this will close a hanging bracket – if this special doc is placed anywhere after when the mistake occurs. But if it is placed anywhere before that it will be one close bracket too many, and that should look different in your result/log. Using a simple binary search procedure you might narrow down to a culprit doc this way also.))