turning deepest children of OPML import into list

Hi all

I’m new to Scrivener but not (M)MD or LaTeX. I’m not sure whether what I want is doable but perhaps I’ve missed something obvious, or someone else has cracked this.

In a nutshell, I want a system where I can put together an OPML document and have a process that automatically converts the last set of children to a list. So it would be something like this

OPML file structure:
I’ve had to write (tab) to show indentation as white-space is being elided in the Preview

This is the first line
(tab) this is a child of first line
(tab) (tab) these are children of child of first line (1)
(tab) (tab) these are children of child of first line (2)
(tab) (tab) these are children of child of first line (3)

Currently, in MMD via Scrivener, this becomes

This is the first line

this is a child of first line

these are children of child of first line (1)

these are children of child of first line (2)

these are children of child of first line (3)

What I would like (because it suits the workflow of drafting in OPML) is

This is the first line

this is a child of first line

  • these are children of child of first line (1) <!- auto-detection that there are no children of this set>
  • these are children of child of first line (2)
  • these are children of child of first line (3)

Does this make sense? Does anyone know how I might do this? My workflow is

Outliner (iPad)/Omnioutliner as OPML/Mindnode [drafting]

-> Scrivener [final polishing and development of prose bits]
-> custom export as .tex to BBEdit
-> compile in TeXShop

You could do all of that with the MMD compile system, it’s quite flexible and would even allow for detection between items with sub-documents versus items with no sub-documents.

Everything would be done in the Formatting compile option pane, so go ahead and fire that up. In the top table you’ll probably see three rows, one for each of the data types in Scrivener: Folder, File Group (files with sub-documents), and Files. In addition to this you can also assign different instructions at the specification of outline level, in a cascading fashion. Hence the “1+” of the default setup. If you added a level spec to Folder, you would end up with a “Level 1” and and “Level 2+”. The latter instruction set now cascades to anything deeper than level two.

So in your proposed example, you would want:

	Level 1
		Level 2
			Level 3+

The Level 2 spec would be identical to Level 1, its only function is to ensure that level 2 items are not treated specially. For Levels 1 and 2 you would only need to leave the Title checkbox on. That generates your hashmarks at the appropriate depth for you.

Level 3 however is going to be where the instructions alter. Now you will want to visit the Section Layout panel and add "- " as a title prefix, and, if you intend to export text content as well, potentially a carriage return in the suffix. It would depend upon what list format you wish to output.

The next ingredient is in the Title Appearance tab. Enable the “Insert title as run-in head” checkbox. This will disable hashmark generation and push the title down into the first paragraph of content. If there is no content—if you are just exporting the outline, then this doesn’t matter, but you can see the importance of inserting a carriage return as a suffix if you are, and do not want the first paragraph to be on the same line as the heading. If you do, something like:

	Prefix: "- **"
	Suffix: "**: "

Might be appropriate. That would embolden the title and append the item content on the header row.

So to summarise:

	Level 1: Title ON
		Level 2: Title ON
			Level 3: Title ON; Prefix ("- ") / Suffix ("<RETURN>"); Run-in head ON

Since we are only doing this for the File type, this spec does not every apply to level 3+ group items or folders. Thus, items at level 5 that are folders would still have hashes “#####”, and any sub-documents they contained with no children would get the 3+ treatment as a list.

This is fantastically helpful. I’m not sure the MMD ‘definition’ syntax (: at end of line) is going to work once it gets into LaTeX (in case anyone else is interested in this) as it’s a fake heading but the use of level+ (and appreciating that clicking ‘insert title as run-in head’ removes the hashes is the clue I needed.)

NB when I preview the Level 3+ formatting in the Compile window it looks like this:

- Title

Main text. Lorem ipsum dolor sit…

but those hashes are not outputted (this threw me at first and might therefore throw others trying the same thing!)

Actually the MMD definition syntax looks like this:

Term
: Definition.

So if you wanted your 3rd level stuff to form definition lists, you would leave the prefix blank and then add a carriage return and then colon space for the suffix—again with the run-in heading set. Subsequent paragraphs would be normal paragraphs though, so it would only work for the first one.

This will work in LaTeX. In fact I used definition environments heavily in the user manual. I adjusted the default typesetting slightly, if I remember right, but it works vanilla as well.

Sorry, I forgot to mention that run-in head isn’t previewed at all in the mock editor. It’s because of limitations in the text engine and how each piece or element within there is stacked in the “editor”.