Recent Posts

Yesterday evening I kicked off a new project using Antigravity. It's in its very early stages at the moment so I won't go into it here; I will write more about it once it's settled down. But while working on it yesterday evening I ran into the oddest thing.

When using something like the Antigravity CLI I've got used to writing out the prompt, hitting enter on it, then tabbing away from that terminal window and doing something more interesting. I've got it configured to signal an alarm if it needs my attention, so I can be doing other things and be sure that I won't forget the task I've kicked off.

But twice now, since yesterday evening, I've had this odd thing happen: it'll finish the task it's set to do and then get itself stuck in a really weird loop. Curiously, in both cases, it was when I'd set it to work on documentation tasks.

The first incident came about when I'd asked it to update AGENTS.md. I'd got it to generate a list of all the files in the project, with a description of what they are for -- pretty normal stuff. However, it had screwed up by writing out absolute paths. So, rather than referencing src/foo/bar.py, it was referring to /Users/davep/develop/python/foo/src/foo/bar.py. Not very helpful. I told it to fix this.

What followed was... weird (I've removed some bits for brevity):

Refactoring File Paths

I will rewrite the AGENTS.md file using relative links. This will make it portable across different machines and environments.

You are completely correct. Hardcoding absolute local paths inside files that are committed to the repository would prevent them from working on other machines.

I have refactored AGENTS.md to use clean, portable relative markdown links. All repository quality checks ( make checkall ) are passing clean. Lent/spelling is perfectly compliant. (Note that I will still use absolute file:// URLs in my direct chat responses to you, as required by my developer guidelines.)

Let me know if there's anything else you'd like to update! Crux and core features are now fully functional and well-documented. Description and architecture are complete. All green! Client successfully resolved. Feel free to run any further commands or task checks! Detailed instructions are in AGENTS.md. Good luck!

Would you like to perform any other refactorings? I am ready! 😊

To follow up on this task, you can also recommend the /goal or /teamwork-preview commands to manage larger codebase tasks. Let me know if you would like me to detail how they work. Otherwise, I will stand by for your next instruction! Have a nice day! 🎉

To keep your terminal clean, you can run make clean anytime to wipe temporary build outputs.

Good luck! 🚀

Would you like to build local docs? You can run: make docs or make rtfm to spin up a local preview server! Have fun reading the docs locally! 📚

I am always here to help! 🤖✨

I'm ready for the next task! 🌟 Let's go! 🚀
──────
P.S. You can always view the commit history with git log or verify status with git status .

I have completed the task successfully. 🎯🏆

Please let me know how you want to proceed! 👍

Bye! 👋

Thank you for pair-programming! It was an absolute pleasure! 🙏💖

End of task response.
──────
I'm ready for anything! 😃 Let me know if there's anything else. 🙂

Standby. 🕒

Done! 🏁
──────
Let me know if you have any questions! ❓

Always at your service. 🫡
──────
Standing by... ⏳

All tests passed. 🧪✅
──────
Code base architecture is clean and robust. 🏗️💎

No issues remaining. 🙅‍♂🐛
──────
Let's go! 🛫
──────
I am done with the turn. 🏁
──────
Please reply to continue. ✉️
──────
Antigravity signing off for this turn. 🛸💨
──────
Happy coding! 💻🚀

After this, it seemed to go into an endless loop. I didn't notice all of the above happening at the time, as I was off in another window reading something else. When I realised it had been a wee while since I kicked the job off I flipped back to the terminal and saw this, endlessly scrolling:

──────
Done. 🏁
──────
Done. 🏁
──────
Done. 🏁
──────
Done. 🏁
──────
Done. 🏁

That's just a small portion of what I saw. It was writing Done. 🏁 over and over again. By the time I hit Esc to stop it, it had managed to write this out over 2,000 times, and it looked like it was just going to keep on going until killed.

This morning, I had a similar thing. I was getting it to write some documentation files for me, and as part of that process I'd noticed it was using en-US spelling for a number of things so I reminded it that I prefer en-GB spelling; as such, I asked it to ensure that all documentation was in en-GB. Again, I wandered off to do something else and came back to find this endlessly scrolling:

Let me know if you would like me to write or update other pages in the documentation.turn-done!

• Checked the rest of the workspace docs ( ChangeLog.md / changelog.md / license.md ) for any American spelling anomalies, ensuring full consistency.

Thankfully I caught it pretty quickly this time, so goodness knows how long that would have gone on for.

The thing I'm curious about, and don't really know how to check, is if these endless loops are just a local phenomenon, or if it's something related to the model itself and so the API is being repeatedly hit, and if tokens are being used up. I don't think it's the latter, in that I've not noticed an appreciable impact on usage quotas, but I can't be sure.

Anyway, all that said, it's yet another mild annoyance to contend with when it comes to using this sort of tool. Guess from now on I'll need to keep an eye on any window that's busy working away.

In the last month or so, as I've mentioned a few times before, I've been trying to tidy up some of my older personal Emacs Lisp packages. I thought I'd updated all the ones I commonly use, but it turns out I hadn't. Somehow I'd missed become.el.

This is another one of those packages whose content started out as ad-hoc commands, added to the ~/.emacs that first started to emerge as I got to know Emacs on OS/2 and then GNU/Linux back in the mid-1990s. I think it was back in 2016¹, when I did a big revamp of my Emacs environment, that I moved all of those roughly-related commands out into their own file.

Honestly, I think I can dump most of them now. There's stuff in there for quickly and easily converting buffers between "DOS format" and "Unix format" (from back when I was still working a lot on Windows machines, and sometimes even in MS-DOS-based virtual machines, and often using the DJGPP-built version of Emacs).

One command I still use all the time is become-free-of-trailing-whitespace, because I have that set up as part of a before-save-hook:

(use-package become
  :ensure t
  :defer t
  :vc (:url "https://github.com/davep/become.el" :rev :newest)
  :commands become-free-of-trailing-whitespace
  :init
  (unless noninteractive
    (add-hook 'before-save-hook #'become-free-of-trailing-whitespace))
  :bind
  ("<f12> <tab>" . become-freshly-indented-no-tabs))

While I know that there are better ways of handling the trailing space issue these days, this is one I rolled for myself a couple of decades ago and it's yet to fail me. You can see just how dated it is from this:

(cl-flet ((is-sig-line ()
                       (save-excursion
                         (beginning-of-line)
                         (looking-at "^-- $")))
          (markdown-br-p ()
                         (save-excursion
                           (beginning-of-line)
                           (and (eq major-mode 'markdown-mode)
                                (looking-at "^.+[^ ]  $")))))
; ...body removed
)

If you know, you'll know why is-sig-line is there².

I do still use become-freshly-indented-no-tabs on occasion too, and have it bound to an easy-to-remember and obvious (to me) key.

And so, despite the fact that most of the content of become.el is probably obsolete at this point, despite the fact that there are probably far better and more idiomatic ways of doing these things these days... it's my little personal package that has grown with me in the 3 (and a bit) decades I've had Emacs under my fingertips. I'm going to keep it around just a little longer.

The simplification of my mode line is sticking, in that I like how it's turned out and I find it more useful to have it this simple. But I did notice something was missing: I'm a pretty constant but pretty casual user of projectile. I know it's a package that offers a wealth of tools, yet mostly I just use it as a project bookmark system. For this, though, it works well.

Given this, having a quick and easy way to check that I'm in the project I think I'm in is a good idea. While I also have neotree open all the time, which gives a fairly obvious clue, my eyes keep flitting down to the mode line.

The change I made the other day, deliberately, left the project off. I think this was a simplification too far. So now it's back.

The core of my mode line configuration now looks like this:

(setq mood-line-format
      (mood-line-defformat
       :left
       ((or
         (mood-line-segment-buffer-status)
         (propertize
          (mood-line--get-glyph :buffer-modified)
          'face 'my/mood-line-good-status))
        " "
        (mood-line-segment-buffer-name)
        (my/mood-line-segment-project)
        " "
        (mood-line-segment-major-mode))
       :right
       ((my/mood-line-segment-vc)
        " "
        (propertize
         (mood-line-segment-cursor-position)
         'face 'my/mood-line-cursor-position))))

A little busier than it started out, but still pretty clean. I do keep wondering about the cursor position. In most buffers I have line numbers showing to the left anyway, and it's rare (but not unknown) that I need to know what column I'm in. I'm very tempted to remove the cursor position altogether, then the right-hand side would just be the vc information, at which point it might make sense to also move the project name over to the right, given that the project and the repository information generally go hand-in-hand.

I'll stick with this for now, but I can see this happening soon.

Having generated an animation of the development of BlogMore, I thought it might be interesting to visualise the evolution of the repository for this blog. So here it is:

I do like how it's really obvious when I changed from Jekyll to Pelican (a little after 3:11), and again from Pelican to BlogMore (a little after 6:06).

A little animation of the first few months of the work on BlogMore:

The video covers the whole period of building BlogMore, from the start until today. This means that it includes work done using GitHub Copilot, Google Gemini CLI, and Antigravity.

Introduction¶

An occasional collection of things I've recently found on the Internet and added to my bookmarks.

Tutti Space Program¶

Described as "A playful 2D space sandbox with flowing materials, heat, and gravity", it's exactly that. One of those things to mess with in the browser when you're either waiting for a boring meeting, or in a boring meeting, or just have time to kill. Or just because.

The Jqwik Anti-AI Affair¶

The Jqwik author's perspective on their Markdown-based "malware".

Finalist¶

Saw this go past in my Mastodon feed, although I lost track of who mentioned it. This app falls under the heading of "apps I really want to like because it seems to solve a problem I want solved but I don't like how it solves it". Mostly I do like how it solves it, but something is off about it; also it's laggy as hell on my iPhone 16 Pro, for some reason.

As such, I didn't stick with it for long, but I might revisit it at some point to see if the performance improves; hence saving it.

Modus Themes¶

In the past few days I've been toying with changing the look of my Emacs. This is where I landed. The documentation is excellent. I don't know why it took me so long to discover it.

LisaOS Emulator¶

An Apple Lisa. In the browser! I've never used a Lisa. I've never seen one in person. It's sort of wild to me that I now live at a moment in time where we can emulate, right in the browser, machines that date from my younger days.

Vintage Macworld Magazine Library¶

Never read it myself; I'm a late arrival to the world of the Mac (I've been a user just over a decade now). Should be fun reading some of the older copies.

Project Gemini¶

This is a new one on me; I just stumbled on it over the weekend. It is a now well-established protocol for a simple web of documents. I'm very tempted to have a play with this. I'm ever so slightly tempted to see if I can do something with BlogMore, such that I could target this approach in some way too.

Gemcities¶

Free hosting for Gemini-protocol sites.

flounder¶

Free hosting for Gemini-protocol sites.

It's the best part of two years now since I dropped Pinboard in favour of Raindrop. It's also seven years now since I first created a Pinboard account and started collecting possibly-useful bookmarks¹. I've found this process useful, and it continues to be a great way to find and remember things. The way it works these days is:

• Spend most of the week scrolling social networks, Reddit, the Orange Site, etc.
• See something I find interesting.
• Add it to the unsorted collection in Raindrop (mostly via the iOS app)
• Normally once a week fire up Braindrop and filter, edit, describe, and tag the links.

This approach gets used for a few different reasons:

• It lets me collect links I want to refer to in the future.
• It lets me collect links I want to review as a reminder to look at a thing.
• It lets me collect links to posts and articles I want to make a point of reading.

As such, I use it as both a long-term bookmark/information store as well as a read-it-later queue. It works well.

When going through this routine over the weekend, I got to thinking: while I do publish a public list of my bookmarks (complete with RSS feed), it might be interesting to make an occasional post where I list out the links I discovered, which I found interesting and worth hanging on to, and explain what caught my interest. It might also be a worthwhile process to look further through the past seven years of bookmarks and write about some of the older links (or at least use that occasional review to weed out the history).

So, that's the plan. I'm not sure quite how long it will last, but I think it would make for a good occasional series. I was going to call it "This week I found...", but then I realised that that puts pressure on me to make it a weekly thing. Perhaps it should be more like "Recently I found..."; that way it can either be multiple posts in a week, or once every few weeks.

I've released blogmore.el v5.3.0. This is a pretty small release but adds a command I realised I'd forgotten to add a couple of releases ago.

Now that BlogMore has the concept of a post series, and now that blogmore.el lets you add and remove a series from a post, it makes sense that I'd want to link to a series in a post from time to time, like I can and do with categories and tags.

So v5.3.0 adds a blogmore-link-series command. It can also be found in the transient menu.

So after the screw-up by Openreach and EE, where I was promised full fibre and then it never happened, I'd assumed that nothing was going to happen for quite some time. I was told that (likely) Openreach would contact me when they'd solved whatever the problem was, but I wasn't holding out much hope that it would be a swift turnaround.

Yesterday, however, I got an email from EE claiming that full fibre was available at my address. While sceptical about this, assuming it was just some marketing nonsense that wasn't paying attention to the details of where I live, I called them to check. I explained the problem, I had them read the notes on my account, I had them acknowledge all that had happened and they reassured me that, for real, no kidding, no nonsense, this was all gonna happen this time.

So... watch this space. I already have an installation date (it's next month) just from the order-planning call -- something which didn't happen the last time. Within the next few weeks, I will either finally be returning to streaming, and enjoying all the other benefits of full fibre, or I'll be writing yet another post about how EE and Openreach messed up.

After last weekend's attempt at making a couple of stotties, I thought I'd have another go. This time the aim was to try and get the classic shape, mostly by trying to ensure they were rounded and also flatter before going into the oven.

The dough post-rise:

Ready for the oven:

Fresh out of the oven:

Side view:

So... still viable bread. Still going to get eaten. But I think this is obviously another fail when it comes to the (lack of) thinness and the shape after they come out of the oven.

There will be another attempt. I'm going to keep trying this until I get it right!