Today I’m going to continue working on the layouts used for emsenn.net. The goal is to, by the end of the day, have the https://emsenn.net/programming/emsenn-net/ page mostly complete: listing its bulletins, logs, and source files.

I’m not entirely sure how I’m going to organize the source files. I think each file of the source should end up its own page, so that there are pages for, say /programming/emsenn-net/config/ or /programming/emsenn-net/layouts/_default/baseof/

This’ll mean writing some new Hugo types: one for hugo-config, and one for hugo-layout. Others might become evident from there.

(I feel like I should make an Org-mode capture template for adding tasks to a project… can I open a capture template from within a capture template? I’ve just tested it and yes I can, so that introduces a new workflow: begin a log, leave it as I go to add new tasks to projects. I wonder if there’s a way to link to the task from the log, like, paste a link to the entry created by the capture once it’s filed?)

Anyway, for now: work on emsenn.net’s layouts.

I’ve recently started working to standardize how my written records are, er, recorded, so that it’ll be easier for me to handle rendering them with Hugo. But this means that I need to rework my Hugo templates, to accomodate the concepts.

In the previous log I sketched out the (rather few) qualities that pieces of writing would have, as well as qualities for two types of writing: logs (like this piece) and notes – short little bits of writing that might get syndicated into a microblog.

The qualities I listed were:

– author
– version history, meaning for now:
– a creation date
– a publication date
– and a date of last modification
– keyword tags

One thing I can’t quite decide on is whether to have explicitly defined /types/ of writing, or whether the Hugo renderer should do the work to infer the type. I think the former, because while that’s more upfront coding (I think), it’s less work throughout the sequence of processing. So, that’s another quality: type of writing.

The next step is sussing out how to record each of these within an Org-mode subtree.

Ox-Hugo [[https://ox-hugo.scripter.co/doc/author/][has documentation]] on how to record an author. Since I use the subtree flow, this means that I should record the author within the =EXPORT_AUTHOR= property.

Ox-Hugo [[https://ox-hugo.scripter.co/doc/dates/#dates-subtree-based-exports][has documentation]] for dates too. It looks like I can use Org-mode’s TODO stuff for it, but I’d prefer to set explicit properties. I’m unsure if I want to use automatic updating dates, so for now I’ll handle it manually.

For keyword tags, there’s again [[https://ox-hugo.scripter.co/doc/tags-and-categories/][documentation]] – here I’m going to use a property instead of Org-mode tags, so that I can use those for Org-mode functionality, like avoiding exports. Plus, I tend to use a /lot/ of tags and so it would crowd my UI.

For recording a type, I don’t see a better solution than a [[https://ox-hugo.scripter.co/doc/custom-front-matter/][custom front-matter]] property.

So here’s a table of the qualities of a log and how to record them within an Org-mode subtree:

| Quality | Assignation |
|————————+——————————————–|
| author | Set the =EXPORT_AUTHOR= property |
| creation date | Set the =EXPORT_DATE= property |
| publish date | Set the =EXPORT_HUGO_PUBLISHDATE= property |
| last modification date | Set the =EXPORT_HUGO_LASTMOD= property[fn:3] |
| keyword tags | Set the =EXPORT_HUGO_TAGS= property |

There are details I’d like to note, about what each value expected is, but I’ll write those into the operations manual, not here.

The final step is creating a Org-mode capture template for logs and notes, which will help automatically create an entry with the appropriate information.

Related, the next step after solidifying this process will be easing the process of actually publishing the updated website, as right now that, not recording notes, seems to be my biggest hurdle.

(And in the future, a way of quickly deducing which tags a piece should have applied would be nice. Rules about what should be tagged and what shouldn’t, I guess?)

Oh – and while “notes” is a rather simple record type, one for say, “programming procedure” might not be, as it’d need to have a record of which programming language it’s for, what library, what inputs, etc., all in a way that the rendering can determine and present.