Damn. Oh damn. My Reddit account is now old enough to buy beer1. O_o
While I probably have accounts somewhere that are older than this, that's still a pretty long time to have held an account somewhere and still be actively using it.
I remember I'd been reading Reddit for a couple of years before I finally made an account; I can't quite remember what prompted me to do that. In that time I've been more or less active there (although seldom one to post things or make comments -- normally I just consume and vote). From what I can tell that suggests I was starting to read Reddit within a year of it being launched.
I vaguely remember those old days. I remember all the conversation when it moved away from being developed in Lisp. I can't remember if I was visiting it around that time.
I do have the charter member badge because, back when gold was launched, I was reading the site a lot and it seemed sensible to support it at the time. I've long since let that subscription lapse. I see zero benefit in Reddit Premium.
For some time, a couple or so years back, when they killed off most third-party clients, I stopped using the site for a while. These days I have got back into the habit of reading it again. While I do occasionally check in on a handful of Lemmy subscriptions, and do keep thinking I should probably look into lobste.rs2, it's hard to break the habit of opening the Reddit app and scrolling for a wee while. I've yet to finally and fully replace it.
I should go look at some of my other longer-serving accounts on websites and services and see exactly which is my oldest one.
Another quick update to blogmore.el, again to fix an issue I've run into with the new frontmatter-handling code. This time it's to address an actual crash that could happen if a property was available but empty. For example, if a post had frontmatter that looked like this:
And I then went to use blogmore-add-tag, I'd get a crash saying:
Wrong type argument: sequencep, :null
The reason being that tags was being parsed with a value of :null, rather than (as before) having a value of nil (which of course meant I had a nice empty list to do things with). It was an easy enough fix.
At this point I think I've managed to shake out any serious issues with the proper YAML-parsing approach to frontmatter, as I've used it to write a handful of posts now.
A quick little update to blogmore.el to fix a couple of issues introduced by the new YAML-parsing approach to reading frontmatter; both pretty much stemming from how falsy values are handled.
Simply put, both boolean false values, and also empty values (something that could commonly happen with tags and series) would end up showing up in the frontmatter as null. This release handles that situation.
Also, under the hood, I cleaned up some repeated boilerplate related to how the cached dump calls to BlogMore took place. The code for categories, tags and series data was almost exactly the same, save for the actual name of the thing being dumped. So I turned it all into a macro:
(defmacroblogmore--cache-dump(dump-name)"Generate a function to get DUMP-NAME from BlogMore, with caching."(let((cache-name(intern(format"blogmore--current-%s-cache"dump-name)))(getter-name(intern(format"blogmore--current-%s"dump-name))))`(progn(defvar,cache-namenil,(format"Cache for the list of %s from existing posts."dump-name))(defun,getter-name(),(format"Get a list of %s from existing posts."dump-name)(or,cache-name(setq,cache-name(blogmore--list-of,(symbol-namedump-name))))))))
and now the defvar that creates the variable that holds the cache, and the defun that creates the getter function for the data, are reduced to this for all three collections of values:
Sure, I probably could have done all of this in a single global, a central getter function, and a hash table, but the macro approach feels so much more elegant, and more... lispy.
As normally happens, I then went on to tag the release on GitHub, followed by writing the blog post to announce the new version. While doing this, despite the fact that it wasn't necessary given the nature of the change, I decided to update BlogMore in my blog's repository. That's when things started to look odd.
I did the usual make
update but nothing new appeared. Now, it's not unheard of that I do this and no new version of BlogMore appears. Often I do it a couple more times and it's fine. So I kept trying every minute or two and still nothing. So I checked back on PyPI. Sure enough, a search showed that it had updated:
(The 16 minutes being about the time since I'd made the release), but when I clicked through it was showing the last version from a couple of days ago. Even when I looked at the release history it was saying the latest version was the previous version:
Odd.
At this point, depending on how I searched and where I went, I'd either see that my latest upload wasn't available, or I'd get a 500 error.
Leaving aside the whole issue of having an account on Twitter these days anyway, I felt it wasn't that useful to point people at a resource that seems to have never been updated, so I did raise an issue about that.
Digging around the status page at some point, despite the fact that the main display was green all the way, I did see a rise in "PyPI CDN Edge Errors". I'm not a web guy, I'm not an infrastructure guy, so I'm not really sure what this would mean, but it sounds like it's not a good thing.
Opening the graph to look longer term, it did seem today was a spike, with another spike quite some time ago.
At this point I left it a while, not announcing the new version of BlogMore. I came back some time later and, finally, I could see 2.43.0 was showing! Also, this seemed to coincide with the above graph calming down again.
Seeing this I went to upgrade BlogMore in my blog's repo/venv and this time it all worked.
Yay!
At that point I left it alone and went about my work day. However, I don't think whatever is going on is over. Despite the fact that it was showing BlogMore as being v2.43.0 earlier today, once things were settled, I just checked again as I started to write this and:
The search index on PyPI shows it as having been updated about 8 hours ago (as I write this), but the page itself shows that the latest version is from 2 days ago. At least installing it gives me 2.43.0:
After recently adding Mermaid and maths support to BlogMore, I got to thinking that it now has connections with a handful of third-party resources. While almost all of them are optional (only FontAwesome comes close to being a hard requirement), it does mean that there are resources the user doesn't directly supply or control, and for which the URLs are hard-coded in the source for BlogMore.
Of course, it's not an all-or-nothing setting; you can just set one of the values. So if you wanted to override the force_graph value it's enough to do:
Hopefully this adds some useful flexibility. As well as giving the option to use a different version of a resource, it also allows you to host your own copy and refer to that instead. Heck, it would even allow totally replacing a library with a different one that has the same API, should you ever find yourself in that situation.
When I released blogmore.el v4.7.0 yesterday I finished off by saying that it was my intention, at some point, to rework the frontmatter-handling code so that it did proper YAML parsing. As often happens with these sorts of things, "some point" ended up being that evening.
I've rewritten everything to do with handling properties in the frontmatter so that it now uses yaml.el. This has a number of knock-on effects. The first and most obvious effect is that anything that is a list/array in the frontmatter is actually properly treated as a list. A good example here is tags. Now you can have your tags look like:
and blogmore.el will still handle things fine. The same holds for series too.
It should be noted, however, that because I'm now using actual YAML serialisation code, most other forms of a list will all end up being transformed into this kind:
and you make an edit to the tags via blogmore.el, it will end up as the version enclosed in []. BlogMore itself supports all three versions so this works fine.
There is a breaking change here too, which in part explains the reason I bumped the version to 5.0.0: because series can now be treated as a list I've removed the blogmore-set-series command and instead replaced it with blogmore-add-series and blogmore-remove-series. Both can of course be found in the transient menu.
Another big change in this release is the way that existing values are loaded up from your blog. Previously, when you went to add a category, tag or series, blogmore.el would use ripgrep (or a combination of find and grep if rg wasn't available) to pull out values to help populate a completion list. This worked fine as long as a) the frontmatter property was all on one line and b) the body of a post didn't contain something that looked like a frontmatter property. With this release of blogmore.el I've dropped this approach in favour of calling blogmore itself and using the dump command to get the actual lists of categories, tags and series.
This does mean that BlogMore needs to be installed in a location where blogmore.el can see it, and to help with this I've added a new defcustom called blogmore-command. By default this is set to call whatever version of blogmore can be found in your exec-path; if this results in unexpected behaviour you can set blogmore-command to point to a specific copy of blogmore.
There is, however, a small downside to this beneficial1 approach: calling on blogmore and parsing all posts to get the values is generally going to be slower. With this in mind I've built in a cache for these values. The first time you load up the categories, tags or series, the values are held on to so that subsequent prompts are instantaneous (meaning there is no further call to blogmore). To ensure this doesn't confuse things, when you switch blog (blogmore-work-on) the caches are cleared. In the unlikely event that there is a problem with this approach, I've also added a blogmore-clear-caches command to force the clearing of the caches.
There are some other small QoL changes under the hood and also to the interface. I've moved some things around in the transient menu, and also ensured that a couple of options are better-disabled depending on the context.
All of this makes the package even more robust. Something that started as a quick hack back in March has turned into a tool I heavily lean on. Hopefully, for anyone who might happen to use BlogMore and GNU Emacs, it'll be a useful daily-driver for them too.
The benefits being: only values in frontmatter appear, inconsistent casing is cleaned up, etc. ↩
You can, of course, set a new one too, but the idea here (as with categories and tags) is that you can quickly find back an existing series and add the current post to it.
Also, as with tags, the expectation is that either a single series is being used, or if more than one series is in play for a post they'll be listed as a comma-separated list. The issue here is that while BlogMore supports this:
series:-Some series of posts-Some other series of posts-Yet another series of posts
the frontmatter-handling code in blogmore.el isn't very sophisticated at all; it doesn't actually handle it as actual YAML, instead just treating it as a set of key/value pairs separated by a colon.
At some point soon I want to give blogmore.el a revamp and base all of the frontmatter-handling code on something like yaml.el. I did do some experimenting last night to drop it in and handle proper lists. It worked well enough, but I abandoned the work as I realised I really wanted to start again from scratch and build blogmore.el from the bottom up using that package.
When I first added it it simply dumped all of the data available about posts within a blog, meaning it was possible to do all sorts of things with the data outside of BlogMore itself. Having done this, and used the result to good effect (and also having seen at least one person also make use of it), I got to thinking that I should probably expose some other data that's going to be helpful.
Given that blogmore.el needs to dive into things like available categories and tags, and given that I'd also like to add support there for the recently-added series support, I realised that dumping those values as JSON would also be helpful.
So this release extends the dump command, adding a set of sub-commands:
posts: dumps the data about all posts in the blog (this is the default if you just run blogmore dump, so keeping the command backward-compatible).
categories: dumps all categories as slug/title pairs.
tags: dumps all tags as slug/title pairs.
series: dumps all series as slug/title pairs.
For example, getting all categories from this blog:
[["agentic-afterthoughts","Agentic Afterthoughts"],["buying-the-steam-controller","Buying the Steam Controller"],["edinburgh-fringe-2023","Edinburgh Fringe 2023"],["reading-2bit-files-for-fun","Reading 2bit files (for fun)"],["swift-til","Swift TIL"],["the-great-github-copilot-meltdown-of-2026","The Great GitHub Copilot Meltdown of 2026"],["the-virgin-east-coast-saga","The Virgin East Coast Saga"],["emacs-d","~/.emacs.d"]]
While this data could have been gathered from the content of the dump of posts, this approach makes it far easier to work with and more accessible; simply put, it means there's less work for the user to do if they just want all the tags (for example). With this, and with a little bit of caching in the code (because this does require parsing all the posts every time), I think it will make for a better approach to category, tag and (when I add it) series completion while writing a post.
When I moved to Newcastle, as a student, back in 1986, I was introduced to many new things. So many new things. Different folk. Different accents. Different backgrounds. People from the south! But, as well as all the eye-opening things that student life had to throw at a working-class Yorkshire lad, there were also all the things that Tyneside had to offer too.
Without question, my absolute favourite discovery was the stottie. This became my go-to food, especially in my second and third years, when I was no longer in halls.
I left Newcastle in 1989 and never went back1, and sadly, have never had a stottie since. While I'm sure I could have found some niche place in the various places I've lived since, they're not a thing you find normally in Hampshire, Lincolnshire or Midlothian.
Meanwhile...
Earlier this week I was sat watching some TV and the cat was chilling on the sofa too. She's a ragdoll, a magnificent collection of floppy liquid floof. It occurred to me that she's not a cat that loafs, she stotties! Seriously, she sits there and just flows into a huge furry circle. I mentioned this to my partner, and then realised that I'd have to explain the concept, given that they're not familiar with the North East of England.
The ensuing conversation resulted in the idea that, to fix my wish to have a stottie again (after I'd done an Internet search for them around the Edinburgh area), I should just have a go at making them!
Which brings me to today. I attempted making a stottie and it actually wasn't a complete disaster.
While I've made plenty of bread in the past, I've never been too brilliant at it and, honestly, it's not something that really excites or interests me. For some reason though, making my own had never occurred to me. So, with some yeast, water, sugar and white pepper...
Plus some flour...
Which I threw together, along with some salt...
And then kneaded for about 10 minutes, then left to stand for an hour while I went for a walk.
I don't think it managed to rise quite as much as it should have, but it also didn't seem like enough of a disaster to stop there. Besides, the lack of faffing is sort of the trademark of a stottie, so I also decided this might be fine. I then gave it a bit more of a mix before cutting into two halves and getting it ready for the oven.
I think this was a step where I went a little wrong. I wanted to try and get the size and thickness I remember (and which you see in plenty of photos online), but I was somewhat hesitant when it came to flattening it out. I was concerned I'd made it too thin at this point anyway and it wouldn't rise much. I was wrong. Next time2 I think I'll flatten it a lot more.
Anyway, I threw both proto-stotties into the oven and about 20 minutes later I had something that was passable!
Neither was really quite the nicely-round shape I was hoping for, and both were quite a bit thicker than I would have liked too. But both were baked well, and looked and felt fine inside too, with the texture having the chewy density that I remember.
As for the taste: they were actually good! They made for good sarnie bread for a slightly late lunch, and also got finished off along with dinner.
Overall I would say that things didn't work out as well as I'd hoped, but for a first attempt they came out okay and tasted just fine. Now I know how I'd do things differently in the future, and it's also given me the confidence to have another go at some point.
As for the cat that inspired this, it's only fair I pay the cat tax.
This is the Internet after all.
I've travelled through plenty of times, but it's been 37 years, and counting, since I was last in toon. ↩
It's probably bad news if I have a Saturday afternoon and evening spare, a fully-charged laptop and a comfy sofa. It seems that when that happens, something like BlogMore v2.41.0 happens. This is a release where I've added two features that could be generally useful, but which I'm unlikely to use in my own blogs.
The first, which to be fair is one I might use (I've used it in documentation plenty of times over the years), is optional Mermaid support. This is off by default, so has no overhead if you don't turn it on. It is turned on by setting with_mermaid to true. Even with this enabled, the Mermaid third-party scripts only get included on pages that include a Mermaid diagram, reducing the overhead.
```mermaidgraph TD A[Start] --> B[Process] B --> C{Decision} C -->|Yes| D[Success] C -->|No| E[Fail]```
If Mermaid is enabled the resulting page will show this:
There are, of course, all sorts of diagrams that can be used and I'm not going to go into them here, or in the BlogMore docs; Mermaid is well known enough and well-documented enough that anyone turning this on is likely to know what they're doing, or where to go to find out what to do.
The second new feature, which I am almost certainly never going to need to use on my blog, is LaTeX-style maths support. As with Mermaid, this is off by default and has no overhead if not used. Even when turned on with the with_maths setting, the external scripts will only be pulled into pages that include maths markup.
To use either, when turned on, you use the usual $ or $$ convention for LaTeX-maths-in-Markdown:
You can make some fun images using:
$$
z_{n+1} = z_n^2 + c
$$
We can say $z_{n+1} = z_n^2 + c$ inline too.
The result of the above will be something like:
Note that some care has been taken to ensure that ordinary use of a $, in currency values for example, is left unaffected. This can't be guaranteed in every possible case, so keep this in mind when turning on with_maths. From what I have read this is a common issue when using such markup.
Both these features were fun to add, with me planning out the implementation with Antigravity, and having a back and forth a couple of times to address issues and get it all working "just so". I'm especially pleased with the fact that it's done in a way where there is no overhead, even when either feature is enabled, if a page isn't showing a diagram or maths markup.
