Compile only includes "Draft" folder or Search Results

I’m trying to compile the manuscript, and it seems as though the only options on the pull-down above the document list are “Draft” and “Search Results.”

“Draft” is the contents of the Draft folder, which is not useful for my purposes.

“Search Results” shows all documents, defaulting to ‘include’ without regard for the ‘include in compile’ setting on that document.

Is there something else I need to be doing to make compile see documents for which I’ve set ‘include in compile’?

Compile really is meant for compiling your manuscript stored in the Draft folder–that is the purpose of the Draft folder, and why the Draft folder can only contain text files (images and such can of course be embedded in the text documents, but they can’t be directly added to the Draft folder in the binder they way they can be elsewhere). “Include in Compile” generally is only meaningful for documents in the Draft folder, which allows you to move documents in and out of there without having to constantly change the settings per document.

It is also possible to compile the text items of collections, however; Search Results is such a collection (although I need to check into this, since it should only be populated with items from your last search and it sounds like it may still be returning everything in compile, which would be a bug) and you can also make your own other collections in the project and then have them available for compile. It should also pay attention to whether Include in Compile is ticked, so likewise that may be a bug I’ll note with Lee; meanwhile, you can check items in the Contents pane of compile to get them included (Alt-click to toggle the checkmark for everything). Non-text items in the collection will be excluded regardless of their setting, since it’s not possible to compile them into a text document. If you need to export these types of files, just select them in the binder and use File>Export to bring a copy out of the project.

That’s an absolutely terrible modality. I really wish I’d known it worked that way before I migrated into Scrivener. I don’t remember the Mac version working that way; maybe by accident I had my projects set up so that everything was in the Drafts folder, but seriously, why in the world would anyone want to have to re-arrange their projects every time they want to compile?

And the language is totally wrong: “Drafts” are not compile source. Drafts are just drafts. There is nothing about the term “drafts folder” that says “use only the stuff that’s in this folder.”

Plus, that means that the “include in compile” checkbox in the metadata is more or less TOTALLY MEANINGLESS for everything in the project that’s not in the draft folder. In other words, it promises something it’s not delivering.

I’m sorry you’re feeling frustrated. Here are a couple of workarounds that I use:

  1. Rename the ‘Drafts’ folder to Compile. Click Drafts, press F2 and type in new name.

  2. Compile from a collection. This saves you from having to rearrange items in the Binder. Click items in the binder then RIGHT click and select Add to Collection. Click Compile. In the Contents pane select the drop down menu, you should see any collections below the Drafts folder. Select the one you require. Compile as normal.

  3. Include in draft is useful when there are documents in draft folder you don’t wish to be compiled, or included in your project wordcount.

It would be nice to compile any document straight from the binder, but compiling collections is the next best thing if you don’t want to rearrange binder.

I hope that helps.

Must have been an accident, I’m not sure, because it has always been this way since even the earliest alpha builds. It’s one of the fundamental properties of the program. There is a place where you assemble your manuscript (draft, paper, work, whatever you want to call it), and then the rest of the Binder which can be used as a freeform area to hold research, notes, and whatever else you wish. The output of a project is a singular document, in most cases: one file. There are exceptions, but in any case it makes sense to have a special area of the binder that is all about the composition and arrangement of what will be this file.

If you do not like the word “Draft” (it isn’t “Drafts”), then change it. If you really do not like it, change it and save your change as a template. Use that to make new projects.

Ordinarily it is not necessary to do that. It might be this time because you’ve got things organised elsewhere, but usually one will work in the way the program is designed from the start and this isn’t an issue. I agree, I’m not sure why one would want to do that either, it doesn’t make a whole lot of sense in most cases since Scrivener’s drafting and revision tools tend to be in-place rather than via duplication, using the snapshot feature. There isn’t usually a need for duplicated drafts, since the duplications are stored in a temporal dimension within the outline structure itself. And for multiple smaller projects (like a series of articles), well that is what the content selection tool is for in the compiler. That way you can have six articles in folders within the Draft and select between these folders to compile them as individual files. No need to swap articles in and out of the Draft to do so.

Except when you want to remove a portion of the book because you feel it is not fitting in right. Say one has this portion as a folder with files for the sections and sub-sections, and beneath those are notes which are not meant to compile. They drag it out of the Draft and into a folder named “Removed Bits”.

Later on they decide it really ought to go back into the book but in a different place, so they drag it back in, all 35 pieces of it. If this information was not saved, ostensibly in order to make things simpler, they would be faced with having to go back and reset all of those checkboxes so that the notes were once again not compiled into the book.

Instead, the state is saved when you drag something out, and you can even set things up to work properly once they are dragged in, which is useful when creating boilerplate structures in a templates folder which can be rapidly duplicated and dropped into the Draft, ready to go with all of their compile flags set the way they should be.