I’m referring to the fact that the formatting itself is open to multiple interpretations, and software isn’t good at that. I am not seeing how this relates to whether this or that font is installed—save to reaffirm that this kind of weird and fragile stuff is why I use Markdown instead of fonts to relay information while writing.
Oh no! I don’t consider that to be clutter at all. To put emphasis to my quote, I was referring to “raw final format syntax”, or what we use Markdown as a front end to produce. Typical Markdown editors work largely within the confines of the specification, and that means creating richer documents from it most directly requires putting the syntax into the writing space, in one form or another.
I personally have no problem seeing Markdown in the editor, and in fact far prefer it. I never had any affinity toward editors that hide it or use syntax highlighting to diminish the legibility of markings (I think Typora was the first to do the former). And so I don’t use Scrivener’s capacities to do much of that either. I get there are folks that do prefer that, and treat Markdown more as RTF is treated (you never really see it), but it’s not for me.
To return and expand upon what I’m referring to, there is an objectively clear advantage in Scrivener’s court when it comes to creating richer documents—those that require extended semantics:
In the top left we have Scrivener, where the gold italic heading is in fact just a Scrivenings title, not styled text (I pretty much outline exclusively, rather than putting hard-coded heading depths into text). The list contains two different styles, one of which is using a feature to pull data, a platform-specific keyboard shortcut in this case, from another outline node via a hyperlink. Replacements are also in use to take easy-to-type shorthand and turn it into format appropriate symbols later. The two example styles here are interface labels, for menus and shortcuts, and preference labels, depicted in bold, dark brown text in the output. (There is also a third style, used purely aesthetically to add a hanging indent to my Markdown list.)
On the right we have Typora, which as mentioned is one of the Markdown editors that strives to hide the fact that one is using Markdown while writing. What we are doing with styles in Scrivener is extending what the Markdown specification itself supports (using an open-ended convention supported by the two conversion engines Scrivener integrates with). We are using the same exact approach in Typora, but as it lacks Scrivener’s hybrid mechanisms, the full raw syntax must be present in the writing space.
Since there is no Markdown for doing any of that, using a simpler editor we’d have to type all of the raw code by hand, or devise macros or text expansion shortcuts to help us do so. The result, as you can see in the top right, isn’t pretty. We have language target code that isn’t recognised by Typora printed into the output as regular text, alongside code spans where the LaTeX syntax itself inserted. Since these types of editors tend to not have much by way of heavy-duty book production features, we have to do more manual labour, specifying symbols codes by hand and doing more static content creation. This is in fact being a bit generous, as to really pull off having two PDFs, one for PC and one for Mac, we’d need to have conditional LaTeX code around each keyboard shortcut that prints a different output depending on a variable we defined elsewhere (as most such tools only have simple export, no processing, automation or compiling).
We are also being generous in that this is one single-purpose output being exhibited. If we were intending to produce two or three different outputs, say PDF, ePub and DOCX, then around each interface label and so forth, we might have to write and edit around stuff like this:
1. Open project settings with the <span class="interface">`\interface{`{=latex}`<w:r><w:rPr><w:rStyle w:val="Interface"/><w:rFonts w:ascii="Linux Biolinum O" w:hAnsi="Linux Biolinum O"/><w:b w:val="false"/><w:caps w:val="false"/><w:smallCaps w:val="false"/><w:color w:val="auto"/><w:spacing w:val="0"/><w:sz w:val="24"/></w:rPr><w:t>`{=openxml}Project` ▸ `{=openxml}`{\menusep}`{=latex}` ► `{=html}Project Settings`…`{openxml}`{\ldots}`{=latex}`&hellip`{=html}`}`{=latex}`</w:t></w:r>`{=openxml}</span> menu command (<span class="interface">`\interface{`{=latex}`<w:r><w:rPr><w:rStyle w:val="Interface"/><w:rFonts w:ascii="Linux Biolinum O" w:hAnsi="Linux Biolinum O"/><w:b w:val="false"/><w:caps w:val="false"/><w:smallCaps w:val="false"/><w:color w:val="auto"/><w:spacing w:val="0"/><w:sz w:val="24"/></w:rPr><w:t>`{=openxml}`{\sopt}{\scmd}`{=latex}`<img src="opt.png" class="shortcut"/><img src="cmd.png" class="shortcut"/>`{=html}`⌥⌘`{=openxml},`}`{=latex}`</w:t></w:r>`{=openxml}</span>).
In case it isn’t clear (
), this is just the first bullet line in the original sample text. I’m not sure if a slick editor interface helps much:
This is opposed to the top left Scrivener screenshot, which never changes, because one style can generate a hundred different kinds of documents. It’s not an earth-shattering idea to be fair, it is after all how Markdown itself works in conjunction with tools like Pandoc. You take one simple input and leave the specifics of output to conversion. The difference between Scrivener and just about every Markdown-focused editor out there is that it is tuned toward stuff like the above, in acknowledgement of the fact that authors are going to need more than HTML and a few scattered goodies.
Don’t get me wrong, these other types of editors have their uses—I use them myself, along with general purpose text editors with Markdown plug-ins. They address areas I wish Scrivener did better in, namely in syntax highlighting and typing aids. But hopefully it is more clear now what kinds of things Scrivener brings to the table as a larger scale Markdown authoring environment. Obviously one wouldn’t use a tool like Typora, or even most any Markdown-based editor, to do this kind of stuff in the first place, so these clutter examples are a little artificial in that sense—but that’s kind of the point.
More complex examples aside, to return to a simpler example discussed above, we can have that same style producing <em>…</em> in HTML (though you might as well just use asterisks in the prefix/suffix fields) doing something else entirely, like \emph{…}, by simply swapping which compile Format you use.
I realise we’ve strayed a bit from the original question, of what basic use of Markdown is like in Scrivener, but hopefully this helps with the overall question of which tool is best for the job.
And by the way, for some projects I use Scrivener’s external folder sync feature in conjunction with Markdown editors for the writing. I get the best of both worlds, when I can, and when I need a more complex document like the manual, I stick with Scrivener for its additional editor level features.