Again with the Markdown

I’m writing a long thing with intention to export it to Markdown, in Scrivener for IOS.

I have things formatted as code blocks which need to start with three tick marks and a language name, likeLSL. I have headings where I want to write ## Heading.

If I compile regularly, everything packs together, my code blocks get no special formatting marks, and I’d have to enter extra newlines. If I ask it to compile with the Convert to Basic Markdown set, then I get ## where all my ##s are, and I get for god’s sake ``` for my tick marks.

Please, is there some way to get this thing to produce useful Markdown, and if so, please link me to a document that shows how to format the document in Scrivener IOS, the settings to use, and the resulting actual Markdown output.


The option to convert rich text to Markdown enabled protects all syntax characters; the primary use of that switch is for those not writing in Markdown.

You can however mark special characters with the Preserve Formatting feature to keep the compiler from escaping them.

As far as examples go: the way I use it is by writing in Markdown and compiling to plain-text without much by way of options (I use the headings by level option). So there is really nothing tricky about it—I could be writing raw HTML for that matter. Scrivener doesn’t mess with the output if you use the plain old text output. It sounds like you’re wanting something a little different from how I write though—hopefully the preserve formatting is good enough for what you’re wanting.

Thanks, Amber, maybe I’ll try that. I keep wanting to use and like scrivener but it seems to take a position on how I ought to work that doesn’t match my position on how I ought to work. :slight_smile:

Thanks again!

Yeah that can be a tough thing to overcome. There have been a few writing programs over the years where there was one critical issue in the design philosophy that made it difficult for me to really bury myself in it. For myself it’s the organisation model that matters. I come from a raw LaTeX in Vim sort of background (though I used LyX for writing for a while), so for me switching over to Markdown was a big improvement, and enough so that I have no desire to really change anything about it. I love that aspect of having one easy to read and compose source text that acts more like a “source code” for document production.

The other thing I like about it is that I can take that skill set anywhere. Scrivener, Vim, Editorial, Trunknotes, DEVONthink Pro, web pages, AlphaSmart NEO—it doesn’t matter. I don’t need features to make my writing functional, and thus the writing tool is then 100% about the working model that supports writing as a process. It also means the text I produce in any program is immediately portable to any other program and I can thus use whichever environment is most productive for the specific task at hand, rather than having to invest and depend upon one single program to do everything. It can mean using physical form factor to advantage as well; e.g. the AlphaSmart, which is just a keyboard and a tiny screen with three AA batteries that last for years. Perfect for pure composition, especially on extended trips—and it doesn’t matter that the device itself doesn’t support any formatting at all. I can get it into Scrivener, ready to produce something as complex, in a document structure and design sense, as even the user manual for it.

So that why I advocate for leaving that switch off and writing pure Markdown. If you’ve already got one toe dipped in you might as well make the jump.

But if that isn’t quite your cup of tea, consider styles and using the Mac for production, leaving iOS for composition only. A style-based approach to writing can grant one a fairly “rich text editor” experience, and with the Mac’s prefix/suffix compile system you can use styles to generate syntax even, like your code block fence quotes. I.e. just mark it a “code block” on iOS and you’re done. Overall I would say it is a superior approach to fiddling with Preserve Formatting and remembering which characters are “special” and which aren’t. But if you are stuck with the necessity of using the iOS version alone to compile for whatever reason, the style approach won’t work to your benefit.

Yes. My web site is all Markdown, separate files in Sublime, but it’s episodic and blog-like, so separate files, plus some indexing stuff in Jekyll, and I’m good to go. So I’m pretty happy writing in pure Markdown, and I’d do well just to forget about Scrivener’s formatting and go, double carriage returns and all.

However, even a single chapter of the book can usefully be done, at least at the beginning, as a few index cards, a few little sections, which I mean to have amount to be a chapter.

The “book” is going to be in GitHub pages, I’ve decided, and each chapter would like to be a separate HTML file. So as far as I can tell I’m doomed as far as Scrivener is concerned.

I could compile to plain text but doesn’t it still come out as one big file? So that won’t do. Or I can export, but then I can’t get it to roll up any sub-files into a chapter. I’ll experiment with that. Even then, would it be such a big deal to let me name the files *.md instead of *.txt?

Maybe there’s something I’m missing, but to me Scrivener’s big advantage, if it has one, would be organization, and it’s translating that organization into chapter-sized chunks of pure Markdown that has me stymied.
I’ll try compiling sections, perhaps. I’d really like this to work …

OK, that almost worked. I’ll report here, hoping to be advised on a better way. Amber, I appreciate your relentless efforts to help. :slight_smile:

I moved a few cards into a folder, selected that folder, told it to compile to plain text. After only a few tries, I learned to turn OFF appending .txt, and to turn on include subfolders. The stuff came out. (yay!)

Formatting was bollixed because I didn’t have double CRs, but that just says I shouldn’t use any Scriv formats that include them. Raw markdown and Courier will probably be the ticket. Shades of my old typewriter, but I digress.

It seems like Scrivener helpfully remembers the name of the last file I compiled to. It would be far better if it would set the name to be the name of the thing I’m compiling. Ideally I could just call the folder “Episode IV: A New” and I’d be good to go.

So I think, maybe, all I’m stuck with is having to type the chapter names into the file name, and maybe fiddle with extensions a bit.

Am I on the right track here? Thanks!

Okay yes, it sounds like you’ve found the method for compiling only the current group to a file instead of the entire draft. That is the only (and so best) way of doing so.

Hmm, it should be doing that, but I might be confused about what is going on here since I don’t get asked for a filename at any stage, it just uses the name of the current compile group as the file name automatically.

thanks, maybe I’ll push forward in this mode for a bit. :slight_smile:

I’d like to document here a bit about my workflow in [trying yet again] to keep my little markdown book in Scrivener, in hopes that my experience will inform future changes to the product.

The “book” is being displayed as HTML pages on GitHub pages, generated by Jekyll, from markdown files. I believe the file sufficient must be .md (not .mmd), but I’ll check that. If GitHub will accept .mmd, that will, I think, make it possible to streamline this process a bit.

Now my normal mode would be to edit a few files and then I’d want to just export those, updating the ones in the GitHub input folder. Then they get committed to my local Git repo, and pushed to GitHub pages.

So I have to remember which pages I’ve changed, and export each one of those one at a time. The file names are picked up from the binder but not the suffix. (Maybe I can name the binder names instead of just intro? I’ll try that.)

If I export the whole thing by clicking Draft and exporting, it wants to create a new folder named Draft (or, I suppose, whatever I call it) under where I point it to. I need the files to go where I point them, which I can do if I do them one at a time (but that requires me to remember which ones I’ve edited.)

So it’s close. My next attempt will be to rename all my pages to be right in the binder, and to try exporting by selecting all the names, but not Draft, in the hope that it won’t create a sub-folder.

Ideally (subject to better advice here), Scrivener would remember which files needed exporting and export just all those, though regenerating all files will be OK if it’ll put the .md suffix on them and not create a sub-folder. It’s a little scary regenerating all the files but that’s kind of the Scrivener way, I guess.

If I’m going to need to export them all (since there’s no way I can remember which ones have changed since last export), then it’d be nice if I could export without creating a new folder for all the files to go in.

So that’s where I’m at. I’m hoping you’ll have idea for a better way to go. Thanks!

Added: I seem to have to keep unchecking the hide extension flag. I’m not sure if I don’t check it if it just doesn’t show in the Export window, or if it would also not put the extension on the file. If the former it’s livable. Latter, not so good. Anyway flag should be sticky IMO.

Did we drift from iOS compile to Mac compile at some point? That might explain my earlier confusion with regards to choosing a name for the output file. I know I suggested that, sorry if I missed where you pointed that out. The rest of this post will assume the macOS version.

If we’re talking about macOS compile, then the file extension is up to you, and it should remember what you used last from one compile to the next (though on a per-project basis). I’m pretty sure Github only takes .md as an extension, and technically speaking it doesn’t parse MultiMarkdown, though there is a good deal of overlap between the two in terms of syntax.

Regarding how to track and compile what has changed, try running a project search for just an asterisk (to find all items in the project), and then at the top of the binder, sort by date. I make liberal use of that capability when working with revisions. The way I keep track of full revision iterations is to create a new file when I start a revision, clearly marking it for its purpose. This file can be anywhere, and can otherwise be ignored and shouldn’t be modified. The idea being, when you run this search you can look for the revision marking file and everything after that point is readily identified as having been touched during the current cycle.

Now consider this: if you run that search and Shift-click select the whole lot that represents the most recent edits, in the Contents tab on the right-hand side of compile overview you can select the compile group at the top of the list (normally “Draft”). Within that dropdown is a “Current Selection” option. With the subdocuments checkbox enabled below that, you should be able to easily compile the stuff that has been revised recently.

As to the rest, I might not be quite understanding what you’re trying to do—but it ultimately sounds like you’re expecting the compiler to be a multi-file generator, or trying to coerce it into being one. The whole program is designed around the premise of exporting one long thing from what you’ve been working on, maybe only pieces of it, but still that thing, and that it won’t be changing its name several times per session.

That said, given that Scrivener can be fully automated with post-processing, if you do want a project that is set up so that in effect there are 15 .md files in the Draft folder, with a quantity of subdocuments beneath each one that should be combined into each of these files respectively, you might be interested in this recent forum thread, and the demonstration project I provided.

Yes, my bad, I did drift into Mac mode as it seemed the iOS version wasn’t cutting it. And I’ve been talking about Export, which does multiple files, or at least trying to talk about it.

I’ll check out the multi-file thingie, it could be a super idea for my style of working.


Export, right, that’s another topic entirely. :slight_smile: That is certainly a way of getting multiple files out, though it does then mean you must constrain each .md to one single item in the binder (for myself, that would feel very limited as I’m used to outlining extensively, down to each subheading in the topic and maybe even further).

With the file-splitter demonstration, you’re basically in control of what constitutes a file in your binder. If that is one single document, okay. If it is a folder with a hundred subdocuments in five sublevels of outline, okay. You can set up what a file is procedurally (e.g. make all top level folders files and everything on lower levels sections within those files), or fully manually, by setting section types in the inspector. The demonstration project I provided takes the procedural approach, but you can also override that with the inspector on a per-case basis. So there is a lot of flexibility here—if you’ve ever used the outliner called LEO, I would say a setup like this provides a lot of what that coder’s outliner gives you, at least in conceptual terms of having a master outline with various nodes that are designated as file generators, and nodes beneath those levels in support of those file generators.

And since you control the automation, you can even disregard the compile target folder, having the script distribute .md files to the correct repository folders, even across different distributions, depending on how elaborate your set things up.

Sky’s the limit once you slap a shell script on the end of things. :slight_smile:

Ah. I had not fully considered what would happen if I exported a folder, had been naively thinking it would make just one file, tho it’s clear it won’t once one thinks about it even slightly.

Perhaps shaving the shell script yak is the right thing to do.It’s a long way from just writing the thing I’m trying to write, though.


Yeah, Export is more meant to be a way of getting your binder contents reproduced to the disk, usually for purposes of a “hard copy” backup. It can be used for other things, but with these limitatiosn.

Sure, but once you get things set up the way you want, it’s pretty fire and forget. My rule of thumb with automation is that if it replaces a series of steps I’d have to take by hand over and over, it’s worth a little up front time in setting things up.