Yeah, to most people Scrivener is a rich text based application. In fact, in its original conception there was no intention to support any form of semantic application to text. Then I came across MultiMarkdown, and realised that if Scrivener could potentially easily call those Perl scripts (and it actually turned out to be more work than just that) with the generated text, it would allow those who care about structured writing to use Scrivener for that purpose. Keith was kind enough to entertain the concept and that is how it got in. However, because it is not the central focus of the application, support for it is less integral. As you’ve already noted, documentation doesn’t cover MMD itself, and so forth. Which is fine, since MMD is documented very well on Fletcher’s site, in my opinion. But this is why the templates are all set up with RTF/DOC export in mind, and so on. I would imagine the vast majority of users never touch MMD, as all they need is a marginally formatted RTF/DOC to send to an editor.
Like I said, they can be made to work, but you’ll have to do a little tweaking here and there to make sure data is going out structurally and not just fontastically.
This should be no problem. I assume you anticipate working on your document in multiple environments? Windows one day, Linux the next, that sort of thing? Otherwise, why the import export cycle?
Anyway, whatever the motivation, as long as you stick to plain text orthodox methods, and use Scrivener purely as document organiser/outliner, this should pose no difficulties. It does mean you’ll lose some of Scrivener’s inline functionality, such as annotations and highlighting. Highlighting (as well as other formats, of course) will disappear. Annotations will export, but since there is no inline commentation syntax in MMD, it will not round-trip. Scrivener footnotes will turn into MMD footnotes, and remain that way thereafter, things like that. And of course if you rely on any of the document notes, references, keywords, synopsis cards, snapshots and other meta-data, you’ll lose that too.
These are all things you needn’t worry about if you work strictly from a philosophy of using Scrivener as a hub, generating various end-products via the MMD exporter. It’s only when you get into round-trip that it will come up. Frankly, I would consider other means for working outside of Scrivener. There is just too much benefit in utilising the application’s full potential to be constantly wiping out the Draft and recreating it using the Draft text alone. I suppose if all you need it for is the Draft content, and all of these other features are useless to you, then carry on. Personally, I would just export the Draft as plain text files (using Export not Compile, so they are all in separate files and folders), and then mark them as edited on the non-Scrivener machine somehow (like putting an ‘-x’ in the filename, and updating the changed files one by one the next time you have access to your Scrivener project.
In short, there should be no Draft data loss or heading structure loss doing round-trip. But only do that if you don’t care about using the rest of what Scrivener can do. Excessive round-trip is not really what the application was designed for. Though as MMD users we do have it a bit easier. At least we get our Binder structure cut up the way we left it. The rich text folk have to manually spit everything back up every time.
I wasn’t clear enough. This isn’t really a convention per se. The importer puts the meta-data information at the top for your reference, so that it can be used if desired instead of lost. The proper way to insert meta-data is to use the dialogue box. Putting it in a document in the Draft will not actually treat it as meta-data. The importer is just doing you a favour. That is why the sample document does not have it there.