Markdown Support?

I have a lot of files I wrote in MD. I want to keep writing in MD. I’ve just spotted Scrivener and and quickly liking what I see… except… There seems to be no MD support.

Converting each of hundreds of files is not gonna happen. As cool as this software seems - I want to jot notes as I have (in MD). I probably want to continue writing in MD - using github for some files and publishing on github pages. I am willing to consider learning to use whatever Scriv wants me to do - but not in one step.

For now I need:

  1. Import my md files into Scriv
  2. Be able to save / export stuff I work on in Scriv to (github)md

So - am I blind and simply not found it in my Windows Scriv 1.x? Are there plans of include it in v3? Does anyone have an easy way to integrate and go back and forth without manualy converting?

It seems at total no-brainer to support MD here - there are simply too many advantages to it outside Scriv.

Is there hope or do I just need to move on and forget about Scriv?

Thanks (and sorry if this has been answered elsewhere - I’ve googled and searched here for over an hour without finding clear answers).

All versions of Scrivener for Windows and Mac support markdown. If you can read the manual (a PDF that can be accessed via the Help menu), it’s chapter 21.

One thing that Markdown enthusiasts have to adjust to though, is that Scrivener doesn’t have a plain text editing mode. You can safely ignore the rich text tools, or you can use them to annotate your text in ways that don’t flow through to .md files, which can be handy for the editing process.

Thanks for your reply.

My - that info is well hidden. I’ve been working my way through the tutorial - hadn’t planned on reading the 300 page manual as well. :slight_smile:

But sadly I don\t see how to import docs. Just compiling them into MMD. Have I missed that?

When I try to import my md files aren’t seen at all. If I save as plain text then I get … well… plan text :slight_smile:

I’m guessing I need to convert to mmd first, then import? Is that correct?


Luckily, you only have to read one chapter if you’re going through the tutorial. I have never read the entire manual, and have no plans to do so. I use it as a way to deepen my understanding of specific features if I’m having trouble understanding something, and recommend most people do the same.

I also must admit that I only dabble with MMD, and mostly start with Scrivener, rather than importing into it. But for those who are more involved in its use, and who may chime into help, are you hoping to write in markdown syntax, or do you want to write without asterisks, and plain-text cross-references? Or do you want to write using Markdown syntax?

As for importing, I’m not sure if version 1 was capable of importing .md file, but it seems like it should. In the version 3 beta, there is a drop-down button that lets you select the types of files it will display for selecting, including “multimarkdown format”. Maybe there’s something like that for version 1?

Yeah the general idea is pretty simple, since Markdown is just text really, there isn’t much to complicate “importing” it into Scrivener. You can do that with simple copy and paste, dragging .txt (or .md even) files into the binder, etc. Scrivener was designed, not to be some kind pause in the Markdown workflow, but rather a tool that works wholeheartedly with it.

Since its original design, we’ve found some people have need of using a word processor in the middle of their Markdown workflow, and intuitively expect Scrivener to bridge that gap. So we did respond to that, and there will be more features along those lines in v3, once it is ready.

In the meanwhile, if you don’t like the thought of using Scrivener to author in Markdown itself, I would suggest using Markdown tools to make the conversion. Nothing on the planet is going to do a better job of making a .docx or .rtf file out of a Markdown file than something like Pandoc or MultiMarkdown. :slight_smile: Once you have those, drop them in like normal into Scrivener.

That won’t help you get Markdown in the end, but like I say, that was never really part of its core design. You’ll have to wait for v3 to get up to speed to full conversion capabilities.

Thanks to you both.

I appreciate saving new or newly edited md files into pandoc of mmd. It still leaves me with an archive of material I can only incorporate with extra steps. Given we’re talking md (super basic format) it’s surprising.

I don’t mind using whatever’s necessary IN Scriv - RTF is great. But in this world of reusing content in various media and forms basic md is king. I can write a snipped that becomes a blog post, a sidebar in a book, a book proposal, slide deck and copy for a video. The end files may all be different formats - but it rocks when I can have one single source file for the text that updates them all.

A lot of my work is with technical teams that work with git - so publishing on githup pages is necessary (and so much simpler than wordpress). That is plain md, not mmd…

Anyway - my dream… one md source for all workflow and output without need to convert for this and that… Is it possible in Scriv? Will it be in v3? If not… is it possible to write a plug-in?

Here’s what I tried…

I’m using the Recipe template

I’m trying:

Click & Drag: My cursor turns into the ‘circle with crossbar’ - I assume it means I can’t do it. It changes into something more positive when hovering over the “i” in the blue triangle at the top but when I let go I can’t find the file anywhere in my Binder list.

File/Open: MD files don’t show up in the default list. I select All Files and do see it but if I select it I’m told I can only open .scv files. Note - I did select Open not Open Project (I did it twice to be sure).

Import: I am offered; Files, Web Pages, Mind maps (this and not md? wow), and Scrivener project (in “import”?) When I choose files I am offered mmd but not md. If I select txt files I get the md code converted into rtf - which means that to continue working with RTF I will be forced to do a lot of editing.

Have I missed something?

Thanks agin - I do appreciate it.


It seems weird to me that round-tripping between mmd->Scrivener->mmd is not supported. As it stands there is basic mmd support upon import when using the “Import and Split” command. There is a least one major omission: captions for images are not imported as such, even if one has a style named “Caption”. On the other hand, this “Caption”—which was imported from the project Amber shared on this forum in her post on how to emulate plain-text—is correctly mapped to MMD upon compilation. Similarly, some styles and comments are mapped to Critic Markup upon export but Critic Markup is not fully supported upon import (missing comments).

As long as round-tripping doesn’t work without substantial manual editing in Scrivener to clean the imported text, there isn’t much use of Scrivener in a MMD-centered workflow. MMD is fine for almost everything. But Scrivener would be of tremendous help in trying to keep atop an academic book project, with features such as splitting notes and comments from the main body of the text, the ability to provide synopses etc.


I’m not sure what you’re looking for when you say you want to round-trip between these things. There are writing tools in Scrivener that MMD does not do (at least not elegantly), and certainly not in a way that would be feasible to import. You can’t even really round-trip with RTF for that matter—there are things that Scrivener does that nothing else does, to my knowledge. Anyone that has exported a document with a rich variety of colour-coded sidebar comments and inline annotations knows that; you end up with one type of notation on import, all colour-coding wiped out. How would even CriticMarkup handle full RGB customisation on inline annotations, never mind the distinction between those and sidebar comments?

The checkbox you refer to wouldn’t really work for what you want anyway, as I understand it. That is for those who actually don’t want to use MMD any more—and like I said above, it’s just a convenience for those with very simple documents. If you need complex word processing import than use Pandoc or MMD—that’s what they are made for, and their authors spend considerable amounts of time making them really good at what they do. Our little checkbox is never going to match that.

I honestly never round-trip, and use MMD in every single Scrivener project I start, so your assertion does not compute. :slight_smile: But if I did, I would use a pure Markdown workflow. It’s a balancing act of what is important to you. Since round-trip is of zero importance to me, I am more free to use Scrivener as a Markdown generating system on top of an authoring system. It’s okay for me if the compiled output is irreversible. Furthermore, that’s just the content, I couldn’t imagine hobbling my use of Scrivener to full round-trip! I use way too many metadata features, internal links, synopses, bookmarks, collections and other mechanisms that cannot be exported in a meaningful fashion. Compiling all of that complexity out into an end format and then later importing that and turning it into my next Draft folder would be a slaughterhouse.

So I guess that’s the moral of the story. If you’re going to use a tool that does stuff nothing else does as your writing platform, then you’re going to have to expect sacrificing some of that stuff if round-trip is so important to you. I really don’t see a way around that, whether you’re using MultiMarkdown, HTML, RTF or FDX. It’s less weird than it is the practical reality of the limitation of these formats. If they were capable of doing everything Scrivener could do, they would end in .scriv.

Dear Amber,

Thank you very much for your quick and detailed response. I use Scrivener since 2011 and wrote my doctoral thesis enjoying most of the features you mentioned. And you were absolutely right if everything I am writing started in Scrivener. For a variety of reasons, foremost among them that many papers originate in quick notes or blog posts, develop into presentations and only then into more substantial writing projects, I find myself starting out in version-controlled MMD. These MMD files are up to 10.000 words long and already contain plenty of footnotes, code blocks (mainly XML and R), and annotations with Critic Markup. Keeping track of footnotes and comments becomes tedious around this length thus would come the moment to transfer everything to Scrivener.

If I want to continue in Scrivener and would like to use all the important features you’ve mentioned, what shall I do? I can import and translate MMD into RTF but this removes some MMD and Critic Markup features, namely captions and comments, which are just imported as part of the main body’s text string.

Should I preprocess my MMD draft? This would also mean, I need to work through my CriticMarkup before import and get rid of all annotations. What is compelling about removing comments (i.e. HTML comments) or about importing metatext as part of the text (i,e. CriticMarkup)?

My preference—obviously a strictly personal point of view—would be to have feature parity between import and export of MMD. This wouldn’t mean, however, translating all the lovely features you’ve mentioned into MMD output.


On another but related note, it would be absolutely fantastic if one was able to select which MMD features to translate to RTF upon import. My academic work is concerned with non-English speaking societies outside the Global north. Yet I write in English, which necessitates a lot of transcription from non-Latin scripts. If a font or font variety does not support a particular diacritic mark it will be substituted in RTF. For instance , let me refer to the journal al-Ḥaqāʾiq from Damascus. Most fonts do not support italics for ʾ and thus the MMD export will be al-Ḥaqāʾiq. I would, therefore, prefer not to translate character styles, such as emphasis and strong upon import. But paragraph styles should be converted.

You might take a look into using the external folder sync feature as a sort of “inbox”. It does offer comment and footnote conversion in plain-text using its own simple bracket syntax. So some form of conversion would be required prior to letting it import.

It’s not ideal, I understand, but what you’re asking for is a bit niche, and as you put yourself—it’s not something that anyone would be able to agree on how it should work. Thus it would require a lot of optional code, a lot of UI to control that, and never mind it would actually require an MMD parser as well, which it currently doesn’t have. And you’re bringing up a level of granularity in conversion that is extremely detailed. :slight_smile:

It would be a major project, for something only a very small subset of the user base would ever even notice, let alone benefit from. That’s why I think it is sometimes better to just state things in terms of scope and design: Scrivener’s focus is on being a writing platform and Markdown generator, here. It is meant to be a zero-word starting point with a fixed end point, not a cog in a wheel of data. One is free to try and push it as far as they can, but it will always be outside of its optimised zone of intent.

To conclude, there is of course one way one can do this: just become friends with CriticMarkup and footnote syntax. :slight_smile: They actually work just fine, all the way through compile. Some even use them in the editor out of preference, rather than using Scrivener’s features. But that’s just going back to what I would do if I were in your shoes: adopt a pure Markdown workflow. Then none of this is a complication, and all of what you need to do can be done with anything that relays ASCII in a sequence of bytes.

1 Like

Dear Amber,

Thank you once again. I appreciate your time and effort I still do not fully understand why Scrivener does not provide parity between MMD import and export. As long as, for instance, captions to plots are not translated into the equivalent Scrivener syntax, one will always have to manually clean up the result.

I am not sure I can see the advantages of Scrivener for a pure MD workflow without support of separate text and metatext streams . In this use case, Scrivener seems to basically boil down to a flexible editing interface (albeit without syntax highlighting), version control, sync, and a transformation engine. All these functions, save for the really slick GUI, are already available in combinations of plain text editors (atom, emacs, sublime text), git and its client software, and pandoc, MMD etc. This is certainly not what I had hoped for. I loved writing a 400-page thesis in Scrivener and would love to come back. But I must realise that once a markdown text is beyond a very rudimentary drafting stage, it can only be imported into Scrivener with substantial manual clean-up, which one wouldn’t want to repeat. Any further editing etc. must, therefore, be done exclusive inside Scrivener.

All the best,

As Ioa noted, that’s by design. Scrivener’s core use case is raw research materials in, finished manuscript out. While certainly there are people who make Scrivener a part of much more complicated workflows, our core audience remains the priority for development and support.