Thoughts for academic Markdown in a future version of Scrivener

[AmberV]

@cavalierex

But to be able to write in Markdown, not get lost in fonts and styles during writing (leaving that for the Compile step)…

Yeah, I guess from your screenshots you use styles, fonts and such way more than I do. I only have a small handful I use for genuinely unusual things, and most of those don’t do anything with fonts—the highlight feature you use a lot is what I prefer. It’s simple, when I see orange I know it is an indexing marker, when I see green I know it is a quote, that sort of thing. The large majority is simple “black on white” typing though (well, dark mode differences aside).

But you seem to be marking everything that is Markdown in a style, and that’s a lot of extra work in my opinion. If it’s what you prefer, then all right, but that isn’t an intended way of using Scrivener + Markdown, is how I would put it.

You could also probably defer a bit of what you’re doing to Scrivener, like tables (which it has a separate conversion switch for). For simple tables it’s good enough, and keeps your text in rows and columns. I only use raw Markdown tables for stuff the basic text engine can’t keep up with. Same could go for lists, which can also optionally convert.

@cavalierex

(Side note: Why would you want to create a figure dynamically like this instead of cut-n-pasting an image, like Scrivener can do so easily? These figures are created dynamically when the code is run, so if a dataset changes or you otherwise tweak the code, you will get updated figures. These are not cut-n-paste figures that you later have to manually update if something needs to be redone, risking to have errata later on when you inevitably forget to update to the latest figure, or to update figure numbering when you moved something around.)

Bit of an aside, but have you played with the <$include> placeholder much? At a basic level you could dump the tikz layout into its own binder item somewhere outside the draft, and then use that placeholder, like <$include:factor c collider>, where the bit after the “:” is the binder title. That would keep the writing area a bit cleaner, not having to scroll around a lot of mechanical text like that.

But what might be of more interest to you, specifically for stuff built from data sets that might get updated, is that you can pull text off the drive with it too, like <$include:D:\path\to\data.txt. Then your scripts or whatever you are using to formulate raw data can produce or update these sources and they all get inserted automatically when you compile.

Callout blocks in Scrivener are distinguished as grey boxes. A Quarto-aware system might know that Quarto only allows 5 types of callouts and therefore color-code them according to type (note, tip, warning, caution, important). That would be amazing, but it is not crucial.

You could do that yourself I think, by using colour-coding for your highlights instead of all grey, and making the five different options available in the editor. The div dots themselves could go into the compiler since you don’t really need to see that any more with the colour-coding, and they aren’t going to be changing from one call-out to the next.

But sure, setting that up as an example for you out of the box, in a project template, is just the kind of stuff I have on my list of things that would be nice to add.

For a LaTeX example, have a look at this post. The screenshot is what I see in Scrivener, and below is what I’ve set up the compiler to turn that into.