Recent Posts

Yesterday I read a rather positive post about BlogMore, which was lovely to see. But... when I saw the link for it over on Mastodon I noticed something wasn't quite right about the description in the preview:

See, when BlogMore makes a post, if the author of the post hasn't provided a description in the frontmatter, the first paragraph of text will be used instead. When doing this the code should strip out any markup (and also skip any initial images, that sort of thing).

But, as you can see, there are things like [Dave][davep] in that description. So I checked in with Andy and that was something that came from the underlying Markdown. After a bit of checking, it became obvious that the code in BlogMore was only looking for and removing inline links, but wasn't doing anything about reference links.

So, as usual, one prompt later and the issue was handled.

As it stands, I don't think I'll keep up with the current approach. It doesn't feel quite right to me. The whole point is that the Markdown should be rendered down to pure text and then the first actual paragraph of text is used. The code I have there now is doing some regexp-based mucking about as an approximate approach. It works, more or less, but it feels like it's implementing a poor Markdown parser when there's a Markdown parser already built in.

Given this, at some point soon, I might have a play and look at the idea of "let's have a Markdown to pure text parser" and then use that. I could see it being useful for other purposes too.

Anyway, the upshot of all of this is that BlogMore v2.6.0 is now available and it handles the stripping of reference links from the description, plus the recently-added strikethrough markup too.

As I mentioned yesterday I decided it was time to update my portable/sofa hacking setup and treat myself to a nice new MacBook Air. It's here (well, I picked it up yesterday evening after dinner).

So far I'm very pleased with the choice. It's light but feels sturdy. The screen is very pleasing to read. The keyboard is really nice to type on (albeit I do prefer the old MacBook Pro, but on the other hand this is a bit more quiet, which matters if you're sharing a living room with someone else). It's fast. So fast! It's also so quiet! So very quiet! And cool too. The Intel-based MacBook Pro would get very warm as I worked; this just stays cold.

The really great part though is the battery life. Depending on what I was doing, with the Intel Pro, I'd get a couple of hours off the cable. On the other hand, last night, I spent a few hours setting things up on the Air and I barely noticed the battery drop at all. This, more than anything, is what I wanted.

Well, okay, I wanted the speed, the quiet, the lack of heat, and the long battery life.

Oh, and the rather lovely "Midnight" colour. It's not black, but it's close enough.

The setup itself went pretty well, although for some odd reason I ran into problems when setting up Emacs. These days I always use Emacs Plus via Homebrew and have never had issues. Weirdly though, this time, if I did the installation method that builds locally all sorts of things went wrong. I don't know if I missed a step or something but I did what I normally do when dropping Emacs on a Mac. So I started again with the pre-built approach and that worked better.

Even then though, I ran into problems with my setup downloading everything. Things mostly worked but I kept seeing all sorts of issues relating to git-gutter and git-gutter-fringe not being able to load (despite the fact they'd downloaded fine, from what I could see).

In the end I gave up trying to get it to all work from scratch and hand-removed and then hand-installed via package-list-packages instead. Not the most scientific of approaches, and one I'm sure I'll regret at some point in the future, but at least I got to a point where I could get other stuff done on the machine.

All of which is to say: if you're reading this blog post I got my Emacs and git environment to the point I can write things and push them out to the world. At which point that's the really important stuff up and going and I can call this "set up".

Once I'm happy that's working, I think it's time to revisit my Emacs setup. While I don't think it needs another complete restart, I think it might be time to at least look through what I have loading in and perhaps remove some things I don't use any more (for example, I always carry around vterm from the days when I was testing every possible terminal I could get my hands on -- that's less important to me these days.)

I've released BlogMore v2.5.0 out into the world. This release is the result of an observation Andy made about the Markdown library used in BlogMore (it might apply to MarkdownIT too, which would of course affect Hike): it doesn't support strikethrough markup out of the box.

I'm not sure I've ever used that markup anywhere on my blog, but I've used it often enough on GitHub (for example) that I just assume it's going to be there (and now I think about it Hike might be okay 'cos it uses Textual's Markdown widget which I know for certain uses GitHub-flavoured Markdown). But, for sure, the Markdown library doesn't implement it because it's not part of the original approach to Markdown.

On the other hand: implementing a form of strikethrough markup is one of the samples in the documentation on writing extensions, so it seemed like a very reasonable thing to add. Given this, one quick prompt to the agents later and strikethrough was added.

Now I'm going to totally have to find a reason to use this markup from time to time to time.

It's just over a month shy of being 10 years since I bought my first MacBook. As I mentioned at the time: I'd bought my first Mac about 10 months earlier than that, had got used to it, had grown to like the OS, and had need of a small and light hacking machine to use while doing a lot of train travel (and I really did do a lot of train travel after that).

Fast forward a touch over 3 years and, by accident of a windfall due to work things, I ended up treating myself to a MacBook Pro. This was one of the last Intel models. It worked well and served as my main hack-at-home machine for quite a long time. I used it to code and edit videos and a bunch of other things. It sat there, on my desk, plugged into a couple of screens, and never really served as a portable machine.

Fast forward around 4 years and, having been using a MacBook Pro M1 for a while through where I worked then, I had a desire to get a M-chip Mac for personal use and settled on an M2 Pro Mac Mini. That thing was, and remains, a beast of a machine. It's set up here in my office right now and I'm sure will last me for some time to come.

The thing is, in the last 6 months, my home life has changed. I moved. I now share a place again. It's nice to sofa hack and hang out and all that "share a space with other people" stuff. To that end I've been using the Intel MacBook Pro again but I'm noticing that it's getting old now. It's not that it isn't coping with what I need it for -- far from it -- but having the fans kick in lots, and just the heat, and also the fact that the OS is stuck in the past because it's now a "legacy" machine... I sensed it was time for an upgrade.

A new MacBook Pro was an option, of course, but that feels like overkill for some sofa hacking. If I want to do any heavy video editing or any heavy coding the M2 Pro Mini is still the machine for the job. The new Neo looked really good too, but the entry-level storage seemed a bit stingy these days and once you bump up to the next level, while still stuck with the same memory, well the price starts to get dangerously close to...

So, yeah, as of today, I've kind of come full circle; a decade on from that MacBook Air purchase I have a new sofa hacking machine coming in the shape of the new M5 MacBook Air¹.

So this weekend will involve me digging out my "new macOS environment" checklist and working through it, getting a hacking environment up and going again. One thing I do want to do is follow that list but also write out a fresh copy, because this time around I want to see if I can get a good Python environment up and going minus the use of pyenv. Not that pyenv is a problem, at all, but I feel like I should be able to achieve everything I need using just uv.

I guess it was inevitable¹, but yesterday GitHub announced a new opt-out approach to learning from people's interactions with Copilot. I don't have anything novel or insightful to say on this switch, and I'm sure folk with better-informed opinions have already rushed out posts and articles about this, but I did want to jot down just how curious I am to see this roll out.

For starters: for me this feels like one of those things that will get a lot of backlash, and in a day or so GitHub will say they're pausing rolling this out while they reevaluate this approach². Then, eventually, they roll it out anyway after a "period of consultation with the community". That sort of thing.

I've not read further this morning, but before going to bed last night it wasn't a happy time in the comments section of the FAQ. I can also see why some would be cynical about this change, given the tone of some of the questions and answers in that FAQ. I'll hand it to them: they're pretty candid and honest with the FAQs, but kinda yikes too.

Here's the key thing I'm curious about, and which I'll be thinking about and watching for movement on in the next few days: all the talk here seems to be about protecting the privacy of the proprietary code of businesses³. That... is understandable, from a business point of view, from a commercial adoption point of view, from a "we want all software engineering departments to use Copilot" point of view. But how the heck are they really going to manage that?

In the comments in the FAQ this explanation stood out:

We do not train on the contents from any paid organization’s repos, regardless of whether a user is working in that repo with a Copilot Free, Pro, or Pro+ subscription. If a user’s GitHub account is a member of or outside collaborator with a paid organization, we exclude their interaction data from model training.

This seems somewhat unclear to me. Let's walk this one through for a moment: my GitHub account is a member of a "paid organisation". My account is also my account, for my personal code, I've had it a long time and it's filled with a lot of FOSS repos and I keep adding more. So which scenario is the right one here?

1. Because I'm currently a member of at least one "paid organisation" I'm always opted-out of this training no matter how the opt in/out setting is set and no matter what code I work on?
2. Because I'm currently a member of at least one "paid organisation" I can opt in when working on code that is from a repository which is mine, but I'm opted out when I'm working on code from a repository belonging to the paid organisation?

I think it reads like it's #1. But then that seems rather odd to me because, if I go and look at my settings right now, I can elect to opt in/out of this training system. If the correct reading is #1 why not just disable that setting altogether and say below it that I'm opted-out because I'm part of a paid organisation?

Which sort of suggests we should perhaps read it as #2? If that, that raises all sorts of questions. How would Copilot know I'm working on code from such a repository? Sure, it's not impossible to infer if I am working within the context of a given repository, doing some fun stuff to work out the origin and so on, but it feels messy. It also feels like a scenario that could end up being incredibly leaky. It really would not be difficult to run into a scenario where I'm working on some non-Free code but in an environment where the licence isn't clear, or where it appears that the licence⁴ would permit such training.

Or... perhaps there's a #3, or a #4, or so on, that I've not even considered yet. The fact that software engineering departments suddenly have to start thinking about this issue (yes, I know, it's been a background issue for a while but this really drags it out into the open) is going to make for a few interesting weeks, assuming people care about where their code ends up.

Who knows. Perhaps, in some strange way, this is how all software ends up being Free.

After adding the stats page to BlogMore yesterday I realised that the main stylesheet was starting to get fairly large. Not so big that it was a problem for downloading (and of course normally it would get cached anyway), just more that it was carrying around styles for things that only appear on one page (the styles for the stats, for example).

So I decided to break it up. Now, as well as the main style.css, there's also:

• archive.css for the archive pages
• search.css for the search page
• tag-cloud.css for the category and tag clouds
• stats.css for the stats

This should keep the load times for the main pages and individual posts just a wee bit faster when first encountered, leaving off all those styles that aren't necessary.

All of which means, along with a wee wording change on the stats page, BlogMore v2.4.0 is in the wild and ready to use.

Hike, my wee terminal-based Markdown viewer/browser, has had an update to v1.4.0. In this update I've made a change I've been meaning to make for ages: some support for "wiki links".

By that I mean the sort of link markup you often see in Markdown documents made with Obsidian:

In other words [[this]] instead of [this](kind-of-link.md)

Personally it's something I seldom need, but on the occasion I have been delving into my Obsidian vaults with Hike I've wished the links at least rendered "correctly", even if they wouldn't fully work.

On that note, it's worth keeping in mind that this "wiki link" implementation in Hike doesn't support something that Obsidian does: find the most likely target file for a given link. If you click such a link, Hike expects the file to be exactly where the link suggests. There's no going off and finding the most likely match in the "vault", etc (Hike obviously has no concept of a "vault").

I'm open to the idea of extending this at some point, perhaps, but not yet. The intention here isn't to build a terminal-based Obsidian-a-like, but instead to build and maintain a workable Markdown browser/viewer (and occasional editor).

Hike is licensed GPL-3.0 and available via GitHub and also via PyPI. If you have an environment that has pipx installed you should be able to get up and going with:

pipx install hike

If you're more into uv:

uv tool install hike

If you don't have uv installed you can use uvx.sh to perform the installation. For GNU/Linux or macOS or similar:

curl -LsSf uvx.sh/hike/install.sh | sh

or on Windows:

powershell -ExecutionPolicy ByPass -c "irm https://uvx.sh/hike/install.ps1 | iex"

I've just pushed BlogMore v2.3.0 up to PyPI. This release has a couple of bug fixes and a couple of significant new features.

The first new feature, which came in as a request, is to add support for control over the themes used for code blocks, including independent control of the themes used for light and dark mode. With these you can specify any of the Pygments styles to use for code blocks. Personally, I prefer to have things blend in, but this now also gives you the chance to have them really contrast (use a light mode theme for dark-mode blog, or a dark mode theme for a light-mode blog).

The other big feature popped into my head earlier today and once I thought about it I had to have it. It's similar to something I had for the photography section of the older version of my website, consisting of a bunch of useless but fun stats and facts about the content.

Things like which hour of the day I tend to post during:

Or the day of the week:

Or the month of the year¹:

This is designed to be turned off by default -- I can imagine most folk would not want this sort of thing on their blog -- but it can easily be turned on with with_stats. The location of the stats can also be controlled using stats_path.

Last night, while tinkering with another BlogMore feature request, I ran into the sudden rate limit issue again. As before, there was no warning, there was no indication I was getting close to any sort of limit, and the <duration> I was supposed to wait to let things cool down was given as <duration> rather than an actual value.

So this time I decided to actually drop a ticket on GitHub support. Around 12 hours later they got back to me:

Thanks for writing in to GitHub Support!

I completely understand your frustration with hitting rate limits.

As usage continues to grow on Copilot — particularly with our latest models — we've made deliberate adjustments to our rate limiting to protect platform stability and ensure a reliable experience for all users. As part of this work, we corrected an issue where rate limits were not being consistently enforced across all models. You may notice increased rate limiting as these changes take effect.

Our goal is always that Copilot remains a great experience, and you are not disrupted in your work. If you encounter a rate limit, we recommend switching to a different model, using Auto mode. We're also working on improvements that will give you better visibility into your usage so you're never caught off guard.

We appreciate your patience as we roll out these changes.

So, in other words: expect to be rate limited more on this product we're trying to get everyone hooked on and trying to get everyone to subscribe to.

Neat.

I especially like this part:

We're also working on improvements that will give you better visibility into your usage so you're never caught off guard.

You know, if it were me, if I wanted to build up and keep goodwill for my product, I'd probably do that part first and communicate about it earlier rather than later.

I guess this is why I don't hold the sort of position that gets to make those decisions.

I've just bumped BlogMore to v2.2.0. This release adds post counts to the archive page.

The overall count appears at the top of the page, with further counts broken down for each year and each month. I've tried to ensure that the counts appear subtle enough, but still readable.

Also, serving the same purpose, but giving more information at a glance, I've added the same counts to the table of contents that appears to the right of the archive if you're on a suitably wide display.

This means I can easily see that I've posted more times this month than I have in any other month since I started this blog. In fact, I've posted more times this month than I have in quite a few individual years in the past.

So... that's today's "I thought I'd added everything but oh look here's another thing to add" feature. Which goes some way to explain why there are so many posts this month, I guess.