Rich text to Markdown frustrations

I’ve been trying to set up a template that will let me edit in rich text, and export to Markdown. It has been a frustrating experience.

By default, the Blank template supports two heading levels. It’s not at all clear how to add more.

If I export from Blank with “Convert rich text to MultiMarkdown” unchecked as in the template, code blocks flagged with “Code Block” style work and I can add styles for things like third level headings, but paragraph breaks in rich text turn into newlines in the Markdown, not into Markdown paragraph breaks.

If I export from the Blank template with “Convert rich text to MultiMarkdown” checked, paragraphs work properly but code blocks don’t work, there’s no good way to add more heading levels, and so on.

The best I’ve managed is to export with convert rich text turned off, and set up styles to handle all the Markdown syntax. Unfortunately there’s no way I can find to customize how “No Style” text gets exported, so I need to create a “Body” style and apply that to all the regular text and make sure I don’t leave any text with “No Style”.

There also seem to be some behaviors that are hard-coded based on style names. For example, any style named “Code Block” seems to result in tab characters before each line, and it doesn’t seem to be possible to remove them using Replacements during compile. I’ve ended up creating a code block style with a different name and deleting the default one.

It would be really helpful if Scrivener could come with a minimal template focused on producing Markdown. If anyone has put one together, I’d appreciate pointers.

By default, the New Folder command adds the new folder as a sibling of the current outline level. The New Text command adds children if the current document is a folder, siblings if the current document is a text.

To add levels, you can either drag and drop an item so that it is a child of whatever level you want, or use the Edit → Move menu to indent/outdent items as desired.

I would definitely recommend using the Compile command, not the Export command, if you need anything more than very basic formatting. In particular, the Compile command makes it easier to handle styles and unstyled text differently.

The Compile command pre-defines handling for a few styles, including Code Block. For others, you’ll need to provide your own definitions. See Section 24.14 in the manual for more information. If you haven’t already, you might want to read Chapter 21 in the manual, and particularly Section 21.5, which discusses the interaction of Markdown and the Compile command.

1 Like

It would be really helpful if Scrivener could come with a minimal template focused on producing Markdown. If anyone has put one together, I’d appreciate pointers.

I’ve certainly given that some thought, but one of the problems with that idea is that there are perhaps two, maybe three, modes of thought in how one can use Scrivener to produce Markdown text.

The route youj’re taking, in fact, is not one that I would often recommend to anyone using Scrivener as a Markdown writing platform. It’s more the sort of thing I would recommend someone try, who has already written a book using formatting, and wants to see the kind of quality they can get with minimal investment (maybe they aren’t happy with the default ePub for example, and want to see Pandoc’s). It’s a limited way of working, one that requires more work to get it working right, at least in my opinion.

Plus, there’s the whole preferential thing of whether using formatting is the best approach to begin with. I’d never abide having to use formatting to produce Markdown, because to me the whole point of using Markdown is to use Markdown. I might use formatting here and there to avoid excessively labour-intensive aspects of it, like tables, image management, footnote numbering and things like that—but to I choose Markdown because genuinely like writing with it, and the bulk conversion way you are coming at this penalises that way of writing by automatically escaping any punctuation mark that Markdown would use. There are ways around that, but it adds overhead to a degree I wouldn’t tolerate. Having to use a special style for “raw markup” every time I want to bold some text defeats the seamlessness and ease with which Markdown is intended as a writing interface.

So that’s something to think about, and maybe given how you wrote this post, maybe you’re already on that path. It sounds like you’ve turned off the global converter and are now starting to put together what we refer to as a hybrid writing approach, where you can mix Markdown and formatting together as you please. To what extent you mix it is entirely up to you, which is the nice thing about this second (or I would say primary) mode of usage.

In short, Scrivener’s design was always built around the notion that those using it as a Markdown writing platform would be using Markdown, not doing everything the can to avoid it. So looking at the feature set from that perspective will help it make more sense. You’re supposed to be able to copy and paste and .md file into the editor and do nothing further to “convert” or “import” into Scrivener. You could, if you wanted to, but you’re not supposed to have to. And by extension you could write in Scrivener using not a single bit a formatting, just pure Markdown (I often do in the very early phases, so that I can more easily integrate Scrivener with Markdown editors to do the actual first-run drafting).

If you want to dive in a bit further into this topic, this is a good place to start.

By default, the Blank template supports two heading levels. It’s not at all clear how to add more.

Do you mean headings in the text itself? I’ve always let the outline drive that, since you can enable Titles for a Section Layout and Scrivener will work out the heading depth for you based on the indent level. It’s much easier to keep things organised by heading in the binder, in my opinion, then having to scroll around in long documents looking for divisions.

But what you’re looking for is the Format ▸ Paragraph ▸ HTML Header Level submenu, which should be saved into the style as a type of formatting. To be clear though, that only works with the global conversion checkbox. If you’re handling things more by hand, then stick with the Prefix fields in the Styles compile format option pane.

Unfortunately there’s no way I can find to customize how “No Style” text gets exported, so I need to create a “Body” style and apply that to all the regular text and make sure I don’t leave any text with “No Style”.

The main question I would have there is what are you needing from ordinary paragraphs that isn’t addressed by how ordinary paragraphs work in Markdown (nothing special, just text separated by an empty line)? Well, the answer to your question is essentially the same as rich text compiling: enable the switch for the Section Layout that prints text to override formatting, and then apply the style you want to the sample text.

To answer one particular way in which this can be of use, I sometimes use a “Definition List” section layout, where each entry in the binder is a glossary term, and each paragraph is meant to be a definition, and thus should be prefixed with a : . So I have a compile style for Definition Paragraphs, which inserts that prefix, and for this Section Layout, it converts “No Style” text to this style, whilst printing the binder item at the top, producing this effect:

Binder Title
: First paragraph.
: Second paragraph...

As for code blocks (and a few other special formatting handlers), I don’t have anything to add to what @kewms pointed you to. These are not hard-coded, though some of the Compile Formats do indeed have some reasonable mappings between stock styles. All of that will need tuning if you make your own styles or build your own Formats from scratch.

Indeed I do not use the tab-generating code block helper that Scrivener provides, either, as I prefer fence quote style in almost all things. You don’t have to delete the stock Style though, just remove the binding in the MMD/Pandoc Options pane, and then add your fence blocks or whatever to Styles. Plus, that gives you the opportunity to have kinds of code blocks, like Ruby Code, or HTML Code, and then your compile style prints:

```html
<p>Text assigned to this style.</p>
```

On that note in particular, I would generally recommending treating the “Basic MultiMarkdown” and “Basic Pandoc” compile Formats as your “New Format” to duplicate from, instead of the stock + button or duplicating from “Default”. The actual software defaults are not good for Markdown users. The “Basic” format variants have much more setup, some reasonable defaults, and good examples for what you can do with styles.

Anyway, hopefully some of these examples highlight how Scrivener can be used to aid in Markdown generation; to be tuned so that it lets you write with Markdown where you want to, as much as you want, while also augmenting what you write and inserting additional markup, making things more convenient when working at a large scale.

1 Like

Sorry, I confused things by using the word “export”. I’m using compile, and I started by taking the existing Basic MultiMarkdown preset and customizing it.

Aha! Thanks, I’d never run across that. I also wouldn’t have guessed it was the right thing since it mentions HTML. I have wondered whether I might get better results from exporting to HTML and then running that through pandoc to get Markdown. Thoughts?

That’s what I want, it’s just that if I turn off the “Convert rich text to MultiMarkdown” option that’s not what I get; paragraph breaks ¶ get turned into single newlines ⏎ in the Markdown document. (Ulysses has a similar problem.)

I think I started down this route because it seems a waste to have an editor that supports styles and just use it like a plain text editor. I don’t have a problem with needing to use a style for emphasis (for example) if that’s what it takes, I’d be doing that if I were exporting to any other format — I always define semantic styles and avoid direct manipulation of format.

1 Like

Thanks, I’d never run across that. I also wouldn’t have guessed it was the right thing since it mentions HTML

Right, it’s one of those things we just added because… well, why not, and like I say, this whole approach isn’t really meant to be the mainstream way of using Scrivener to write Markdown. So putting Markdown in the menu title would maybe confuse things a bit.

We could rethink that though. I have at times wondered why we don’t respect the HTML level setting in regular old Markdown output. Well, like I say, in most cases it is better to drive all of this from the binder anyway. Only at maybe H4+ could it be often argued as maybe the headings becoming more decorative than structural to the composition of the text, at a writer’s level anyway (what we need to know, when conceptualising the outline or the skeleton of the text).

I think I started down this route because it seems a waste to have an editor that supports styles and just use it like a plain text editor.

Oh yes, I totally agree with you, to the effect that using an expressive formatting capable text editor to compose Markdown is one of the things that makes Scrivener special. Not only do you have capabilities such as those described in this analysis of the style system in Scrivener, but just being able to use a rainbow of different highlighters while editing, or striking out text in a way that doesn’t insert markup—these are all extremely valuable capabilities that are difficult or impossible to find in text editors that must derive all visual presentation upon the disposition of the text (syntax highlighting).

But like I say, being able to do stuff like that doesn’t imply you have to give up on writing with Markdown. To instead not use it just as a plain-text editor (this would be what I referred to a third way of using Scrivener, but I doubt many do), but to find a sweet spot between plain-text and formatted text that helps us write more efficiently, and focus more of our time on creativity instead of problem solving the mechanics.

And that’s where I’ve struggled with making a template to help people get started. Where that sweet spot is going to sit is, I feel, very personal. You will find my personal line demonstrated in the user manual project. I use styles sometimes purely cosmetically, for no purpose other than to set the text in the editor. I often use Markdown, particularly for links, because I like to also use links as a writing tool, and Markdown gives me that choice of when to express a link to the reader as well, by putting brackets around it.

You put an official template in the software and extol its uses in a help file, and that makes a pretty strong statement on how the software should be used, when in reality one can indeed as you say, go all the way to using “Emphasis” to inject asterisks around text, if that pleases them more than typing it in, to the person that refuses to even use Scrivener’s footnote system because they prefer to have a human-friendly anchor naming setup rather than one that is serial number generated.

We know this, because we can look around the forums here and see people putting one single text file called “Scene” into a folder called “Chapter”, over and over, 25 times in their Draft folder, because that’s the example the Novel template gives. Therefore one should use the software that way, right? :laughing: Never mind that is tantamount to putting one PDF or JPG into its own folder, hundreds of them, in your file system.

That’s what I want, it’s just that if I turn off the “Convert rich text to MultiMarkdown” option that’s not what I get; paragraph breaks ¶ get turned into single newlines ⏎ in the Markdown document. (Ulysses has a similar problem.)

Ah, I see what you mean. I’ve always double-spaced my lines, from decades of habit at this point (even prior to Markdown coming around, I wrote in LaTeX before that, and you double-space your paragraphs there too). If that’s not your habit, you might be interested in this tip. Speaking of LaTeX, those instructions are in fact for LaTeX writers using Scrivener, but never mind that, I’ve tuned all of the stock Markdown-based compile Formats to have these latent settings as well, all you have to do is switch them on.

Anyway, I think you’ll get along with the “hybrid” approach, as described above, and in Chapter 21’s introduction, if you are no stranger to using styles to declare textual meaning. That is the bread and butter of this approach.

1 Like

Well, the paragraph spacing tip got me closer. Unfortunately once I’d set up Override text and notes formatting and made the “no style” paragraphs work, and then fixed up the code block and block quote styles, I found that newlines were being ignored. So I’ve given up and changed to the “use Scrivener like a plain text editor” approach.