start! start! start! start! start! start! start! start! start! start! start! start! start! start! start! start! start! start! start! start! start! start! start! start! start! start!

this website used to be written manually, html and all, but that got annoying awfully quick!

start? start? start? start? start? start? start? start? start? start? start? start? start? start? start? start? start? start? start? start? start? start? start? start? start? start?

my website is quite simple, a few set layouts made using articles, sections and spans, all laid out in a human readable (i guess?) way

most of the meat is from the styling, css that splits everything into sections visually and positions them correctly using flexbox (which is everything you will ever need)

but content wise, a lot of it is simple text with images here and there

this didn’t make it abhorent to edit, i used semantic tags so i didn’t have to dig around endless divs, but it could easily be written as a title (the scrolling header you see at the top), followed by maybe an image and then paragraphs of text

so what if i got markdown to do it for me?

zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola! zola!

zola is a newish (not at all actually) rust-based ssg (static site generator) which uses the tera template engine which is inspired by jinja2 and django

looking at it, it’s pretty fit for what i need, not overkill at all, so can it actually get my esoteric wishes made into html elements?

not really, but it was close

so onto the next option!

comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak! comrak!

comrak is a commonmark and github markdown parser and renderer, again in rust

you can use it as a cli, but the library is plenty good

what got me interested in this was the create_formatter macro, which allowed you to easily create the kind of hooks i needed for rendering my custom markdown insanity

but in the end i never got a working product out of it, i was kinda dumb with how i tried to implement this (and after i figured out how to do it with hugo, i probably could)

hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo! hugo!

you know what hugo is, i’m not gonna teach you about it, but i will show you the horrors i made

first off, this is the kind of markdown i want to be writing

# title
body

# second title
![figure](path)
body2

seems readeable enough for me, even when not formatted, and it doesn’t have shortcode syntax vomit

everything will be centered around headers which will act as delimiters for the different articles, so let’s mess with them

headers! headers! headers! headers! headers! headers! headers! headers! headers! headers! headers! headers! headers! headers! headers! headers! headers! headers! headers! headers! headers! headers!

they’re actually called headings, and hugo provides a way to hook the way they’re rendered with this

the mistake i did with this back when trying comrak was that i tried to start and end articles whenever a header appeared, which went miserably

now, the headers simply get rendered as you see above, not nested in anything, but with comments around it

<!-- end-article -->
<!-- begin-article -->
<header>
    ...
</header>
<!-- end-header -->

so each header closes the last article, and then starts a new one, the end-header is just to make my parsing easier

of course the last header will not get any close, but i just match the end using regex in that case

regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex!

now for the fun part

as a hugo partial (which is basically a custom function), i loop over a range that matches <!-- begin-article -->.*?(?:<!-- end-article -->|$)

regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex!

now i have each article nicely as a string, which is a header followed by a bunch of paragraphs

using more regex, i extract the header, but because of how hugo’s exposed regex works, i can’t grab capture groups from the normal find function, so i need to use replace to replace the entire article with just the header:

<!-- begin-article -->(.+?)<!-- end-header -->.+?(?:<!-- end-article -->|$)

this extracts the header into capture group 1, and then i replace the entire thing with it, giving just the header

regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex!

i then extract the figure, which is right after the header

(?:<!-- begin-article -->.+?<!-- begin-figure -->(.+?)<!-- end-figure -->.+?(?:<!-- end-article -->|$)|.*)

again taking the figure into capture group 1, which i then replace the entire article with

if you’re wondering why everything is wrapped around (?:…|.*), that’s because some articles don’t have figures, like this one!, but i still need to match the entire article…

regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex! regex!

i then extract the body of the entire article, excluding the figure and header

<!-- begin-article -->.+(?:<!-- end-figure.*? -->|<!-- end-header -->)(.+?)(?:<!-- end-article -->|$)

and finally i can build the html with the extracted strings

<article>
    {{ $header | safeHTML }}
    <section>
        {{ if $figure }}
            {{ $figure | safeHTML }}
        {{ end }}
        <span>
            {{ $article | safeHTML }}
        </span>
    </section>
</article>

lovely isn’t it?