Unfortunately I don’t have Windows 7 to test with, only Windows 10—and I can insert thousands of curly braces without the compiler throwing an error. This seems like a very specific thing to be OS dependent upon though—are you sure that MMD execution works in general, you can use the other output choices, and if you just type in one word into a blank project it compiles to .tex—only fails when braces are involved?
If so, it’s probably not a Scrivener error but a bug in MMD (I’m not sure if they have implemented more informative command-line failure reporting yet, or if it is still just a generic dialogue). One way you’d test for that is by compiling an .md file from Scrivener and then converting it to .tex with multimarkdown.exe on the shell.
But you can also get more detailed logging output by enabling Show internal error alerts
, in Settings: General: Warnings.
And further along that vein, many of the things you are reporting here are specific interactions of MultiMarkdown syntax and how it generates .tex. Scrivener knows absolutely nothing about LaTeX, minted, and even very very little about Markdown itself. It’s by and large leaving all of that up to you and passing your content through the conversion engine.
If you aren’t pleased with how MMD generates minted code, you will have a much better chance of response to your feedback on the MMD Support
Also, it kills Scrivener’s potential role in automated processing of technical material (via CI/CD), for which I’ve almost developed a product that requires users to purchase Scrivener (nudge, nudge, hint).
Well on that matter specifically, since you do have precise output control of LaTeX via the pass-thru syntax, you are not limited one bit by MMD’s decisions of which package to use, etc. And in fact, Scrivener is the antidote to this problem.
You’re just at the moment conflating Scrivener with MMD, which is totally wrong. The actual fact of the matter is that Scrivener is a capable generator
for LaTeX syntax, as well as MMD, etc., while abstracting that generation from the writing mechanism, into the compiler. It just doesn’t do most of that by default—you have to tell it what you want.
There are a number of tools for doing this, but the two you’ll want to use the most are:
- Styles: in the Styles compile format pane, note the paragraph and overall prefix/suffix fields. Here is where you can insert custom output based on simple semantic markings made in the editor. Text can be marked “Code Block (HTML)” in the editor, and then you can implement a precise, custom minted environment you’ve created, via the compile settings. Or you can create a different compile format that exports these to Github Markdown.
- Section Layouts: if styles are the semantic tool of choice at the text level, layouts are how you encode specific implementations into the outline itself. You could create an “HTML Code Block” section type in your project, and put your snippets into the binder as discrete outline items. Then in the compiler you would design how these types of items should be printed. Again, the choice is entirely yours, and with the pass-thru syntax you can implement detailed custom code to any of the output formats. If you are creating an ODT document, you can implement custom ODT XML into the document output, for example. In fact I use this technique in some of our provided compile format examples—pop open the “MMD OpenOffice Document” compile format and examine the styles I’ve defined for indexing. These inject raw ODT XML to help a user build an index at the end of their book.
So the key things to take away here are: Scrivener can generate specific document implementations through compiler setups, which means the content can remain safely abstracted from these details. If MMD doesn’t do something at all (like indexing) then you can add that “feature” to your syntax or your stylesheet. If you don’t like how it handles code blocks, you can roll your own.