I’ve realized that I’m re-doing a lot of logic Hugo comes with, via its “Lookup Orders,” and so I need to reorganize my layouts before I go any further.
I feel like I actually made some progress with my website over the past few days – like, the pages seem actually intelligible and easy to follow! And that’s honestly a good encouragement to write these sorts of log entries: if not for a wider audience, it might be nice to look back on what I had to say about past days.
I mean, most folk who take such journals do say they’re nice, but I haven’t and don’t want to assume!
The weather today is fairly nice, after light showers and intermittent storms yesterday and a few days earlier. I don’t have any big plans for the day: tinkering with my website was a big part of it, specifically writing more things to help speed up writing logs, tasks, etc.
Beside that, I need to tidy up around my apartment, and I think I might try and do some beadwork today, but the rainy weather has my nerve damage acting up, so I’m not really up to much hard work.
As my partner reminded me over my shoulder, we do have an overhaul of the garden space coming up: the corn has to come up, and it’ll be time to put down new seed! The weather has been so unpredictable, it’s hard to plan what’s going to be in-season, especially given the urban environment. I’d love to get down more field peas but I’m out of those seed.
So I’ve made good progress on things so far today, it’s still just a matter of cleaning up the existing layouts, and I think writing some documentation, though I’m not sure best how to organize that.
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 made good progress today overhauling the website’s layouts, following the new organization laid out in recent logs.
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:
– 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.
In my previous log entry I wrote about how I basically use computers to handle pieces of information, but I have two different systems for doing it. One way to unify these systems is by standardizing the output of the information I’m writing in one system so that it can (once an interpreter is written) be interpreted as data by the other.
The system I’m using now is Org-mode, Ox-Hugo, and Hugo, and the system I’d like to use is my MUD engine, written in Racket.
In my MUD engine, different /things/ have /qualities/ that define their capabilities.
For writing, the metaphor would be, different /pieces/ have a /type/ that defines their /rendering/. A /piece/ that’s a /type/ of poetry might be /rendered/ with center-justification, while an essay might need to make sure it’s /rendered/ with a bibliography.
Accomplishing this starts with drafting various /types/ of /thing/ that will exist on my website, and what their /qualaties/ are. Then, I’ll figure out how to integrate that data into the Org-mode records I’m working with in a way that can be read by Ox-Hugo, so that I can create renderings for the various types.
The first record type – gosh, my language here will need firming up – I’ll work on will be for my logs.
Oh, an important thing: types can have parents, things that give them some basic qualities by default. So, logs would be a type of writing.
Qualities of Writing:
– version history
– creation date
– publish date
– last modified date
Qualities of Logs:
– keyword tags
Qualities of Notes
– keyword tags
I’ve recently been getting back into using my computer more, which mostly means dealing with pieces of information. I was thinking about it and, boiled down, there’s two ways I do this:
It feels like I was never asleep last night, though I was in bed trying to rest. It hasn’t set a good energy for moving into today, when I have more preparations to make for Hurricane Isaias, but I got a lot done yesterday.