Can't get "Number of Hashes By Level" to work

Scrivener
, ,
1

Hi Folks. Sorry, this has been discussed before, but I can’t make it go. I have an document with several nested folders, all set to “Structure-based” as the Section type. In the Section Type definitions, I just have two types: “Heading” and “Body Text”. (I do have some others, but they are unused for this example). The “Default Types by Structure” setting in the Section Type definitions has all folders set to the “Heading” type, and all non-folders set to the “Body Text” type. In the compile format, I have two Section Layouts: “Heading Layout” and “Body Layout”. I’ve assigned the Heading section type to the Heading Layout, and the Body section type to the Body Layout. The Heading Layout has the “Number of Hashes” set to “By Level”. I assumed that this would obviate the need to create additional section types (like heading2, heading3), since the a heading would just get the correct number of # given the compiled document structure. But this isn’t happening. All folder, regardless of nesting, get a single #. What am I missing?

FWIW, I’m just trying to output a .md document w/ appropriate headings (for Pandoc to pick up), and the “Compile for” setting is for markdown. Thanks.

2

Solved. Here is the issue, for others: I was using the results of a search to populate the compile list. This flattens the structure, so “by level” does not have the desired effect.

3

Ah, yes, it is pretty literal about applying the structure based on what you see in the Contents pane. This allows you to, for example, host multiple blog articles in your Draft folder, maybe topically organised two or three levels deep. You select one article from the top drop-down and compile it, with its relative top-level being “#” instead of “####” or whatever it would be in absolute terms.

If you do want to force the matter, as you note you can create Section Layouts that are fixed to a Markdown depth no matter where they appear in the structure. But I would say in most cases it is better practice to have all Markdown files use “#” at the highest level, and make use of the conversion engine’s mechanism for offsetting what that means to H3 or whatever. With Pandoc there is a offset setting in the Metadata pane in Scrivener. With MultiMarkdown you add a metadata key for “Base Header Level”, where a value of “2” means “#” = H2, and so on.

4

Thanks, Amber. So, one follow-up question (no good deed goes unpunished):

It seems that the conversion engine’s mechanism for offsetting only works if the top-level folder is selected directly from the drop-down menu. It doesn’t work for “Currently selected” (which defaults to the “absolute” level of the folders/text). Is there anyway to make it work for “Currently selected”?

I’ll explain why. I make very little use of the Draft folder. I like to keep media files alongside writing, and the Draft folder doesn’t allow that. For example, I like to keep the talk versions of the things I write (in power-point form) alongside the written version. The written version is tagged properly, so I never try to ‘compile’ a powerpoint, for example. Organizationally, it is pretty easy and once one has different mini-project within the same Scrivener document (say, like the blog-post structure you mentioned), it is much easier to navigate then having two folder trees, one in the Draft folder, and one in Research, that replicate the same semantic structure.

But the compile menu is pretty limited when it comes to non-Draft folders. I can populate the compile menu with the results of a search, or with “current selection”, but the drop-down menu is only populated with the Draft folder. I understand why the results of a search don’t ‘report’ structure, but “Currently selected” seems like it could. Could it? That way, I could select a any folder and have the offset be handled by the conversion engine.

I assume the answer is NO, but worth asking. Also worth asking if this might be considered a feature request… thanks.

5

Hmm, yes I see what you are coming from in avoiding the Draft folder that way. Aside from the heading levels matter itself, have you considered making heavier use of the Document Bookmarks feature? I realise that doesn’t entirely address the desire for avoiding duplicate hierarchy, but something to consider is that you could have a structure like this instead:

Draft/
	Article One/
		section a
		section b
Research/
	Topic/
		Subtopic/
			Supporting Material.pdf

Then let’s say ‘section b’ wants “Support Material” to be conveniently accessibe. We open the inspector to the Bookmarks tab and drag that into the “section b” document bookmark list. Now it can be viewed in the preview area below, or easily opened into a split view in the main editor, depending.

And now you can organise your supporting material more topically (or by whatever criteria makes sense for them), and even more easily use the same material for multiple sections.

In other words: the design of the software is such that it is meant to “flatten” research and writing content without having to coerce it all into a single outline.

That all aside, I think it will be difficult to get exactly what you want the way you describe having it set up. There is in fact a way of using the current selection with the outline structure, but it involves using the Filter tool (the funnel button to the right of the main group selection). That is how I would most often use Current Selection, which is one of the filtering criterias available. Instead of building a fresh new list from the criteria it subtracts everything from the master list that doesn’t match the filter, leaving the original structure intact.

But to use a filter like that you need a structured selection to begin with, and the only feasible way of getting that is via the Draft folder. So that’s what I mean about it not really helping you out.

I think, to make your approach work, you will have to settle for forcing hash levels by Section Types and Layouts.

As for whether we could modify Current Selection, with the Include Subdocuments checkbox—yeah, probably. It’s worth consideration, but I would caution that in general, compiling non-Draft material is a bit of a niche approach. I would strive, wherever I could, to find a way to make use of the Draft folder given its advantages—perhaps using something like the above as a way of working with supporting material.

6

Thanks for the very thoughtful answer. I’ll try the Booksmarks approach for a bit. Thanks.