[WIP] feat: Support org-file parsing to hiccup content

[the-alex]

trafficstars

Opening this PR so you can see where I'm at here. Turns out there's a library that exposes an org->hiccup function -- wondrous! Sadly, it only takes a string, so I tried slurping it and realized ~sci doesn't support~ we didn't expose slurp in the injected namespaces. Ok, understood. Looks like I'll need to do it in core.clj or something.

Basically just putting this up so I have a place to talk it.

[rschmukler]

I haven't tried yet, but you might be able to directly add slurp to the map on core.clj#L101.

[the-alex]

Appreciate the comments! And apologies, I think if this were anyone else's project I wouldn't have opened a WIP PR like this.

[rschmukler]

I don't mind! Reminds me of the good ol' days!

[the-alex]

Okay, I was giving this thought today:

The spirit of this project seems to be getting up to speed with a singe statik page as fast as possible. This means that anything adding complexity or extending functionality should be either dirt cheap at the top level, or explicitly supported as something nice in the DLS.

I will argue that consuming markup and generating an html asset from it is pretty inline with the project, so the question is how much explicitly to support it in the DSL. Adding a helper function to return the title and content of a given org file is alright, but I want to think about whether this makes sense as it's own asset type, or at least a better top-level function. One can imagine applying a directory of org files to a template function, generating the equivalent of an explicit def-assets for each one.

[rschmukler]

Sorry on the delay on this. The parse-org function looks good. I would look into also adding tree-seq which would allow someone to grab all the files in a provided directory path.