Is there a way to set 'structure-based' section types to ignore lower level folders

I have a project with a binder structure as follows:
Draft > Topic 1 (folder) > Area 1 (folder) > ‘My Document’ (composed of many sub-docs at various levels of hierarchy)
(There is also Topic 2, Topic 3, etc. with similar structure)

I want to compile ‘My Document’ as a markdown file for further processing. I want to use Scrivener’s structure-based compile to set the markdown heading levels in My Document.

The problem is that Scrivener compile detects My Document itself as already being a Level 3 heading (### in markdown), due to its position in the binder hierarchy. Is there any way to tell Scrivener to ‘Ignore folders’ or otherwise to start its structure-based organisation with ‘My Document’ as Heading level 1.

I realise that there are hacky workarounds. Eg, I can move ‘My Document’ to the root folder before compiling, or find/replacing #s in the markdown file. Both of these are fiddly and become time consuming when I am compiling many documents at once. Hoping that there is some better solution available.

Thank you!

Yes, that’s fairly easy to do, no need to workarounds!

The first thing I would try, if you’re just compiling this one “document” all by itself and never intend to compile everything in the draft at once, is to set up your compile group correctly. The compiler is actually has a special feature designed to handle cases where the Draft folder isn’t one thing, but maybe a sequence of articles, books, TV episodes or whatever.

  1. In the compile overview screen, at the top of the Contents tab on the right hand side, set the Compile dropdown to “My Document”.
  2. Click the Treat compile group as complete manuscript setting, and as well turn the Include text of containing group on.

And that’s it! Because we are considering the “My Document” folder (and everything below it) as the entire document, all higher levels of hierarchy in the actual binder are ignored. The highest level of item shown in the Contents list below is level 1. If you had left the second setting off, then that’s a good way of having a “silent” container for each document, and in that case the child items directly beneath it would all be level 1.

This perfectly illustrates why named section types are easier to work with than structure-based Compile.

To a point I would agree with that. That would be something I’d do for this project even if I don’t necessarily need them for compile. Having “Topic”, “Area” and “Document” section types that are set up in the default structure would potentially make things easier for some tasks. For example if you wanted to run a search for all Areas, if they are typed then that’s very easy to do.

I think for this, simply selecting the compile group scope so that “Document” is the top level is good enough, and is less complicated than working with Types. You could do it that way, but given how Scrivener assigns Markdown heading depth by the relative compile group structure means not having to worry as much about aggressive typing.

It’s very different with rich text workflows, because there is no inherent heading depth structure. Then you do need “Part”, “Chapter”, “Section” and so on, to whatever depth is needed. With Markdown you do not need any of that because Markdown handles that kind of logic itself. Setting up a Markdown project is much more abstract. You often only need to define whether a thing has a heading or not.

As I alluded to above, you can force it as well, if you want. The Section Layouts configuration allows one to set a specific Markdown heading level rather than making them structure-based. So you could go in and create a “Chapter” type that is assigned to a layout that only ever prints “##” around the heading text. For some projects that may be necessary, and you could do things that way for this project, but it’s a lot of extra work that you really don’t normally have to do.

It’s one of the reasons why I feel Markdown-based compiling is simpler and more straight-forward than the stuff people have to learn to configure rich text based work. With our Markdown built-in compile formats, many of them only have three different Layouts supplied, because there are only three variations that really matter: Text, Text with Heading, and Heading. Formatting, header depth, and everything else comes from the Markdown processing layer itself.

Thank you, this worked perfectly! May I suggest (as a feature request) that these options are added to to the ‘Current Selection’ option under the compile dropdown menu? This is the default when selecting a document in the binder and heading into compile, and its counter intuitive that you get different options by selecting the same document in two different ways in the same dropdown menu.

Thanks for this too.

I don’t disagree with that, I’ve never quite understood why there are different various exclusions to the feature set, depending upon what kind of compile group selection you make. It seems it would make things simpler for most people to just have the same options available.