As exporting of bullet lists created via the Cocoa text editing system are not dealt with during export, I switched to using the markdown syntax. My understanding of the list syntax is to start a line with an asterisk, plus, or minus sign, followed by a space, followed by the text of the list item.
Scivener ignores this in all three MultiMarkdown export formats
Contains a sample .scriv file as well as the three types of output it generates.
As it stands the “bug that’s not really a bug” of not processing the Cocoa lists as well as this one described here make Scrivener really difficult for me to use. I’m generating technical documentation that requires a lot of bullet lists.
I posted a corrected version of the .scriv file, and an example HTML output from this version.
Basically, Markdown needs spaces between block level elements, such as lists and paragraphs. That is why your paragraphs were all grouped up together, too. The underlying philosophy behind Markdown is to have a source document that looks appealing, as well as an output document. Too many mark-up syntaxes sacrifice the source document’s appearance. So, a good way to make a paragraph look like a paragraph in plain text is to have a couple of lines in between them. It is one of those odd places where we find ourselves composing a plain text document in a rich text editor. You just have to keep in mind that when using Scrivener+MMD, you are really just working in plain text. The conventions you use in a plain text editor might not be the conventions you would use in a rich text editor.
Look at it this way: Scrivener is not an MMD authoring tool, it is an RTF authoring too. It just happens to facilitate MMD text that has been placed within it, and does a few neat things with Binder order and meta-data. Even the actual function of turning an MMD document into HTML and so on is being handled by Fletcher’s Perl scripts and XSLT files, embedded in the Scrivener bundle.
OK, that makes sense. It was not at-all obvious to me that lists wouldn’t be required a new paragraph (or that a list didn’t imply a new paragraph), nor that a paragraph required hitting return twice. Reading the syntax more closely, it’s a little clearer (though your example is way more clear). It’s inconsistent with how the RTF editing works (hit return once == new paragraph), so I didn’t think about it.
I’ve been really struggling with this a lot, but I’ll take that over to another appropriate forum.