Something I would add to the mix is the notion of using the external folder sync feature for all matters that involve integration with a larger Markdown-based toolset. In essence, this approach would sit right in between your first two stated simplest approaches.
Here, the discussion was primarily about linking together Obsidian’s fantastic note-taking capabilities with Scrivener’s long-form writing platform to create a greater whole than either could provide on their own. But the basic concept, of having Scrivener dump .md files out into a folder somewhere, files that it keeps itself synced with, making easy integration with other tools that are adept with loose files.
Definitely consider throwing a shortcut onto the File ▸ Sync ▸ with External Folder Now menu command. That will be your “compile”, if you will, your one-shot update—though in this case it can be a two-way update if you want it to!
So one thing that should be self-evident there is that the less formatting you use the better, for that particular way of working. Using Scrivener much more simply will only benefit the use of third-party Markdown tools in integration with Scrivener. Now if you read down in that thread you’ll find some comments on when it does make sense to bring more of the workflow exclusively into Scrivener.
That’s certainly not a necessity though, particularly for some projects, and particularly in the early phases where pure drafting is being done. Then, I would argue, there are good arguments for eschewing much of the “fancy stuff” and sticking to CommonMark in the editor so that you can use other editors freely, which nobody will debate, do a better job of helping one write Markdown.
If you’re thinking of all the window management that might incur, it doesn’t have to be that way. Scrivener’s project window is extremely flexible, to the point of becoming a very narrow outliner that can be set alongside another program’s editor+preview window. You develop the outline on the left in Scrivener’s window, and do the writing on the right. It’s really not that different from having multiple split editors open in Scrivener. As you noted in your original post, at this level you’re using it more for its organisational capabilities than anything, and that’s a lot of benefit all by itself. There isn’t much out there that works to this capacity like Scrivener does.
Here we have the Scrivener project window pared down to an Outliner view (more on why in a bit). This narrow window can be placed alongside anything else. I’ve never been much for live preview myself, but if I really wanted it in Sublime Text (which is on the right), it is a plug-in away. What you put on the right side is up to taste.
Setup instructions...
- Select the Draft folder in the binder.
- Press
Ctrl+3/⌘3to switch to Outliner mode.[1] - Use
View ▸ Binderto toggle that off. - You’ll probably also at this point want to click on the little arrow above the scrollbar and toggle off most of the columns. I’ll sometimes just stick with Label and Title & Synopsis. I use the synopsis to jot down ideas for what I want to write in the section, as I usually build out outline while writing, when I get ideas for other topics.
You can make the interface even cleaner with:
View ▸ ToolbarView ▸ Text Editing ▸ Format Bar. If you’re writing in plain text mostly, this bar is mostly useless anyway, but it’s entirely useless for this kind of setup, and thus just a bunch of clutter.- And optionally, in the
View ▸ Editor Layoutsubmenu, you can toggle the header and footer off.
Now without the main binder, if you are indeed intending to work in more than one high level folder, rather than just sticking to Draft, then a good tool to be aware of is Edit ▸ Find ▸ Quick Search. Ordinarily this shortcut puts your cursor into the Quick Search field in the main toolbar, but if you turn the toolbar off, it pops up a window that dismisses automatically when pressing Enter.[2]
I like editors such Vim, VS Code and Sublime because they are as agile as Scrivener is when it comes to keyboard management and navigation, but most importantly are, at their roots, extremely powerful text editors—a thing many Markdown editors decidedly are not. I like Obsidian, don’t get me wrong, but I’d honestly rather write Markdown in Scrivener. I do use that tool, but not at all for its editor, that pretty much stays in read-only preview mode.
It’s a little hard to see in the screenshot, but I’m actually editing three separate text chunks, with the view split vertically and two tabs in the lower split. I can effortlessly jump between sections via its project-wide searching and opening tool (the project, in this case, is Scrivener’s sync folder, but given how these editors work, I could easily add multiple sync folders to one project).
In my opinion, the agility of such text editors really mitigates some of what might seem up front concerns with sync folder usage: the granularity of Scrivener’s outline. It’s blurred out, but you can see I’m editing a small chunk of text in the lower split. While it has no “Scrivenings view”, the rest of how it is used does not feel substantially different from using Scrivener’s project window—both are very keyboard shortcut driven and make jumping between sections by name easy.
And hey, if I need Scrivenings, that’s easy. I just double-click on any section’s icon in the left window to hoist the outliner view to that area (or with it already selected, ⌥⌘O / Alt+Shift+O), and hit Ctrl+1. Done. When I’m finished getting a bigger look at the combined text I hit Ctrl+[ to jump back to the full outline. While this setup makes Scrivener look deceptively simple in a screenshot, it’s important to keep in mind that little narrow window there is full blown text editor view, with all of the many things it can do (full project navigation, collection management, filtering, brainstorming, snapshot revision review &c). That’s why we are using an outliner view here instead of a binder (well, that and you can’t hide the editor, so you might as well use it).
In my opinion, all of this above is an answer to the analysis paralysis problem. If you aren’t sure where to go with Scrivener yet, that doesn’t have to be an impediment to getting started with the basics. Use it like a text editor. Use it with a text editor. Treat its outliner as a file manager at first, so you can bail out if you don’t like the program, and take your sync folder with you (but do start outlining as soon as you feel it, because that’s where the power is—anything can throw .md files around in a list). Don’t bother with the contingencies and branching flexiblity—until such a day arrives that you hit a wall, and maybe one of those things is your answer. Then you learn that, introduce it into your process, and keep working otherwise as you did.
More than any other way of using Scrivener, Markdown users have a more natural capability to just get in there and use 1% of Scrivener to get real solid work down, and gradually build up from there in a way that doesn’t require extensive revamping as you learn new things. The Markdown you type in is 100% identical to the Markdown Scrivener can generate, or be “programmed” to generate, in the end. It all looks the same in the .md file, right alongside each other. You hardly ever need to go back and “upgrade” your markup unless you really feel the burning desire. And that fact, by itself, should help in just diving in and starting to use it.
On the matter of “one shot” compile, I made a script for that ages ago, which you’ll find in this post. Two caveats: the actual macro file attached to the post was made ages ago, I don’t know if it will still drop in as functional in a modern copy of Keyboard Maestro, but if not the basic formula described in the post should suffice to recreate it. The second caveat would be that in the years since then Apple has messed up file dialogues so that they are slow even on fast systems, and sometimes no longer buffer keystrokes. So that warning about maybe needing another pause may be more necessary even on a screaming fast machine.
With that method I could setup Scrivener’s styles to kind of pseudo match markdown formatting or not…doesn’t matter, the compile process would chuck it into jekyll for me and I’d see the preview there. I’m kind of leaning towards this option.
I do a little of that, but mostly only for the things that really do benefit from it, like hanging indents on bullet lists, block quotes and code blocks (mainly for an alternate tab stop setup). It may seem a bit silly, but it actually looks better in my opinion than what a lot of text editors can do anyway and with shortcuts on the few I use regularly, it’s really not a bother since writing with Markdown itself is so simple and effortless.
Most of what I use Scrivener’s rich text for is editing marking though, as I had to say over here:
I only use styles to generate markup when I really need to, or when it’s a bit too cluttered for my taste. But most of my projects do not need more than Pandoc+CommonMark. That actually covers a lot of ground with nothing more than what can be done at full writing speed.
Also, I just realized that I will need to be able to generate separate article markdown files, Scrivener seems to want by default to compile the whole thing into one massive end format document.
Two things there:
-
In the Contents tab on the right side of the compile overview window, there is a dropdown at the very top (probably set to Draft). Set that to “Current Selection”. Now with everything else set up the way you want, your export process becomes selecting the parent outline item that represents the article and hit the KM macro. If you also keep all of your YAML metadata (or whatever Jekyll uses) in the outline instead of the compile settings, then you probably can manage with generic settings that get reused for entirely different pieces of content, each with their own title, pub date and so on.
Hint: if you are hitting limits with “Current Selection”, set it back to Draft, then click the funnel icon to its right and enable filtering. This also has a “Current Selection” filter, only this one extracts the selection from the original outline instead of treating it as a flat list, and also grants access to the front/back matter features as you are now doing a “full” compile (that most of the draft is filtered out is irrelevant).
-
The compiler is programmable! If you want a thousand files instead of one, or if you want to turn it into JSON and feed it to a website API for automated publishing—why not.
But I am wondering if I should get into the compiler and consider setting up the right set of styles, so that markdown is specifically NOT written into scrivener (will be compiled later based on styles and such). If I do it that way I have more options down the road of switching to a different variant of markdown or whatever, or perhaps publishing to PDF etc.
While on the surface that is true, and I can see why some might want that, on the other hand if one already has a foot and a half into the Markdown realm then in my opinion there is very little above the Markdown section of the Compile-For dropdown that is compelling enough to sacrifice a workflow over. With Pandoc and Quarto in the mix, everything you can do with Scrivener can be done lots better elsewhere. DOCX? Yeah, Scrivener’s output can’t hold a candle, and particularly if you try to use it to format the text, which ostensibly is the only reason you would want to. I.e. the best way to use Scrivener’s native word processing output is to struggle to turn everything it does off so that you end up with something almost as (but not quite as) clean as what Pandoc gives you, so that you can, like Pandoc, dump the raw styled output into a template. So why bother? The only reason to bother is if you don’t at all use Markdown.
One-click output with Pandoc...
This is straight out of the compiler, via Pandoc’s template system (well I did regen the ToC), and represents a collage of page layouts rather than the actual output (which includes blank pages to force recto layout for major breaks, but makes for a weird screenshot).
You can’t do most of what you’re seeing here with Scrivener—at least not a in way that makes for a good, well-formed document where what you see here is 100% a product of the stylesheet, all the way down to the numbering, page flow header/footer switch-ups, drop caps and so on.
ePub? Again you will spend hours to get output as clean as Pandoc’s ePub output. Now here Scrivener does have some theoretical advantages, but mainly for people who are not comfortable enough with CSS to design a book with it—it’s great for that. Even then I would say there are plenty of tools that can help you generate decent CSS from GUI tools that can, with a few tweaks, be dropped into your Pandoc compile settings—such as Scrivener. 
Quick and dirty PDF is probably the best argument for what you’re describing. Most Markdown tools will be deferring to LaTeX for that, which can be quick and dirty if you already know it, but if you don’t, it’s anything but. That leaves ODT/DOCX and using one of those word processors to pump out a PDF. Not a bad solution, really, and just a few extra clicks. There is nothing in Scrivener that will give you a better result for less effort than that, as demonstrated above.
If you still aren’t sure though, use styles, why not. There are many Markdown-only writers around here that work that way, without a drop of “syntax” in the editor, that have no intention of using Scrivener for anything other than its Markdown output. I’m not saying with the above that one shouldn’t use Scrivener’s writing kit if they are a Markdown writer, I just wouldn’t want to sacrifice external folder sync and having a whole phalanx of tools to work on my material with, for that reason alone, because I personally never use Scrivener’s rich text oriented output for anything at all other than QA testing. A styles-only workflow would be, for me, a mere matter of aesthetics or to avoid excessive LaTeX or other final syntax in the editor (as the Scrivener user manual would be). But, we’re way beyond the basics at that point.
Or click the button in the toolbar, refer to the screenshot in §4.2.3, The Group Mode Toolbar Button, in the user manual PDF if you don’t know where that is. ↩︎
Only hitch is a known bug that makes it so you can’t actually navigate to Draft and Research with it. I get around that by creating my own top level folders in these early phases. It’s easy enough to relocate everything into Draft once it comes time to compile. ↩︎