This system is too simple for a complex site, but is good enough for mine. I'm intending to add support for a partially automated blog, but the manual effort now is low enough that I don't particularly care.
Due to the way the SSGSS system works, different Markdown engines can be swapped in for generation, with different pros and cons. These are a few I have at least tried:
smu: Small and fast. Used by suckless!
discount: Has a few nice extensions
pandoc: Massive and slow, with many major extensions. More suitable for use with a few large files, rather than many small ones. Can mess with M4 by escaping single-quote characters in code blocks.
The requirements for a Markdown processor to work with SSGSS are as follows:
.mdextension so I can move between the Markdown source files by using the
gfbinding in Vim. However, on the actual website, the links must point to the generated html files. To solve this, I can use the following M4 macro:
This allows me to link to the Markdown file in the source, but have the link redirect to the html file after it is processed:
m4_define(`SSGPAGE', `m4_patsubst($1, .md, .html)')
I could theoretically make it more useful by automatically inserting the Markdown link syntax, but that is so simple that I decided I preferred just replacing the extension.
This is an oversimplified view of the SSGSS pipeline:
markdown < page.md | m4 -P > page.html
There are additional headers and M4 macro files loaded, but the key point is that the Markdown engine is called before M4. This means that M4 macros cannot insert Markdown, since once the text reaches M4, Markdown conversion has already occurred. This is primarily done so M4 doesn't get confused by Markdown code blocks, which are delimited by back-tics (`).