Posts from 2026

Rogallo v1.2.0 is now available. The main change in this release is the kick-off of support for the Gopher protocol.

As I've mentioned before: Gopher is kind of an unknown to me, in terms of actually using it. I'm aware of it, I've known about it ever since I first got on the Internet back in the 1990s, I have a half-recalled memory of dabbling with a Gopher client at some point back then, but I had no conscious knowledge of its workings. So, when I say "kick-off" above, I say it because I suspect there's going to be more work to do to make it work "just so".

However, right now, gopher:// URIs are supported in Rogallo.

The approach to supporting this is pretty simple: given a gophermap, as pulled from a server, Rogallo converts it into Gemtext and then displays it using the normal Gemtext viewer.

There is more to Gopher than just displaying the maps, of course: there's access to all kinds of resources. Where possible, Rogallo will display text-based resources within the viewer; all other kinds of resources are handed off to the operating system as they probably need applications and tools that Rogallo doesn't offer (viewing images, playing audio, etc).

Searches (item type 7) are supported, and when following such a link, you will be prompted for input, which will be used as the query.

Note that, for the moment, there is no support for extensions to the protocol such as Gopher+. Doubtless I'll look into doing something with this in the future; Rogallo's development is incremental and for me it's all about having fun (re)discovering new/old things.

There are two other notable changes in Rogallo v1.2.0:

• I've modified the ordering of entries in the history search so that the items appear in most to least recent order. While being able to type in things to find back a location is the primary use, I also found I was often pulling it up to find something I'd visited very recently.
• I fixed the "view source" status being sticky during navigation. If I was viewing the source of a location, and then navigated to another location (by using the Back command, for example), that other location would also show the source. The status is now reset every time you navigate to somewhere else.

That's it for this release. There's still a good few things on the TODO list so I'll be tinkering and enhancing for some time to come. As always, questions or suggestions are very welcome.

Having spun up Port70 as a support library for my effort to add gopher support to Rogallo, the next thing I needed was some code to parse the "gopher map" responses that you get back from Gopher servers. While this could have been some code in Rogallo itself, much like with Gemtext, it seemed sensible to put it in its own library so it could be useful elsewhere.

So... GopherMap v0.1.0 is a thing. Its main provision is a class called GopherMap, which is used to parse some text you give it. Its items property is then a tuple of GopherItem objects. Each one of those objects has a type property which can be used to check the type of the resource.

Because Rogallo heavily relies on MIME types to make decisions about what to do with content, each ItemType has a best-efforts-guess mime_type associated with it. This will make it pretty straightforward for me to decide if a resource from a Gopher server is something Rogallo can display.

All of this has prompted me to have a go at creating my own little Gopher site to help with testing. As with my wee Gemini capsule, this is all thanks to tilde.team.

I've just made a small bug-fix release for Rogallo. v1.1.1 fixes two (mostly) cosmetic issues that were reported by a user. From the ChangeLog:

• Fixed cosy_link_jumps not being loaded from configuration when Rogallo starts up. (#230)
• Fixed viewer status line being lost when maximum_document_width is set to something other than 0. (#231)

Thanks to fab¹ for alerting me to these issues.

One other small change in this release is that the version of Port79 is included in the output from the diagnostics CLI command.

It was, of course, inevitable that this would happen. After spinning up Port79 so that I could add finger support to Rogallo, it made sense that I start to think about Gopher support too. So here we go: Port70, a similar library for async interaction with Gopher servers.

This is going to be a bit of an adventure for me. While I'm long familiar with the existence of Gopher, and I'm fairly certain I used a client once or twice back in the 90s, I've never really had dealings with the protocol so know very little about it. Which is a good thing: something new (old?) to learn.

My plan with this is to add the GopherURI class to the list of URI types that Rogallo understands and handles and then provide a method of displaying and navigating the result. I think the cleanest and easiest way of doing this will be to add some code that transforms a menu response into gemtext and then just let the viewer widget display it as normal; each of the links in the menu being turned into gopher:// URIs.

This should be fun to play with. I'm looking forward to pulling it all together.

I've just bumped Port79 to v1.0.0. There's no significant change in this release, other than the addition of the usual dunder-based metadata that is common in Python libraries; somehow I'd managed to leave it out in the last couple of releases.

Now that I've successfully added finger support to Rogallo, and the library is working out well, there didn't seem much point in letting it hang around in zero-point-whatever-land.

Rogallo v1.1.0 is now available. This release includes a number of new features and improvements, plus a small cosmetic fix.

Diagnostics¶

On the off chance that someone else does use Rogallo, and needs help getting to the bottom of some sort of issue, I thought it might be useful to add a diagnostics command to the CLI. Right now it's pretty simple, just dumping some version and environment information.

$ rogallo diagnostics
# Libraries
bagofstuff: 1.2.1
cryptography: 49.0.0
gemtext: 1.0.0
rogallo: 1.1.0
textual: 8.2.8
textual_enhanced: 1.6.0
textual_fspicker: 1.0.1
wasat: 1.0.1

# Python
Compiler: Clang 17.0.0 (clang-1700.3.19.1)
Executable: /Users/davep/.local/share/uv/tools/rogallo/bin/python3
Implementation: CPython
Version: 3.14.0

# System
Name: Darwin
Release: 25.5.0
Version: Darwin Kernel Version 25.5.0: Mon Apr 27 20:40:51 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T8112

# Terminal
Detected: ghostty

Finger protocol support¶

This was something I was interested in adding, and a couple of people have already requested it, so Rogallo now has finger support. This has been added in a couple of ways. The first and most obvious is that finger: URIs are now natively supported in Gemtext content. So now if you follow a finger:// link you'll see the response in Rogallo itself.

The other method is to use the new !finger command that has been added to the application's command line.

Of course, in the command line, you can also just enter a finger:// URI if you wish, which I guess is a third way of doing it.

Finger URIs are recorded in the history, and can also be bookmarked.

Using an external editor for user input¶

This was also something I was keen on doing, and then someone else happened to ask for it: support for swapping out to an external editor for writing user input. While the current mechanism is fine for entering a one-liner -- or composing a very short message -- a proper editor (for me that's ideally one with the ability to check spellings) is generally going to be far more useful for a longer body of text. So, with this in mind, the internal editor can now optionally swap out to your text editor of choice.

If you have either VISUAL or EDITOR set in your environment (VISUAL beats EDITOR), Rogallo will let you swap to it by pressing F3 in the internal editor. You can also override that choice by setting external_editor in the configuration file.

Personally, I'm finding this is working really well with emacsclient. From now on, I'm going to find writing content in Geminispace a lot easier.

Blended pre-formatted text¶

Now that I've been wandering around Geminispace some more, I've noticed that a common use of pre-formatted text is for logos, ASCII art, that sort of thing. Generally, the sort of things that are best presented with the background the same as the surrounding text. A different shade of background is fine if showing code and stuff, but I feel that this:

looks better than this:

To this end, I've modified the pre-formatted text rendering so that, by default, if pre-formatted text has no alt-text, the background is the same as the surrounding text. On the other hand, if it does have alt-text (and so is likely the name of a programming language, which implies syntax highlighting, which in turn implies you want it to stand out), it isn't blended with the rest of the text.

If your preferences differ from mine, you can control this with the new blend_pre_formatted_with_background configuration file setting. It takes a list of alt-text strings that should be blended. By default it looks like this:

    "blend_pre_formatted_with_background": [
        "",
    ]

That is, by default, it only blends empty alt-text pre-formatted text. As it happens, Station uses alt-text for the logo and the user image, but I'd like them blended in too, so I'm running with this:

    "blend_pre_formatted_with_background": [
        "",
        "Station logo",
        "User image"
    ]

Doubtless I'll add others as I run into them.

Fixed mouse hover effect¶

The last change is a small cosmetic fix to mouse interaction with links. When the mouse cursor is over a link, there should be a hover effect (that is, the background should change colour). This wasn't working if you had link stripes turned on. This is now fixed.

A quick update to Port79. When I kicked this off I'd set up the FingerURI class so that it was pretty permissive in what it would accept. So, for example, you could do any of:

>>> FingerURI("davep")
FingerURI('finger://davep/')
>>> FingerURI("davep@example.com")
FingerURI('finger://example.com/davep')
>>> FingerURI("finger://example.com/davep")
FingerURI('finger://example.com/davep')

Nice and handy, right? Accept pretty much any input and turn it into a finger URI. However, once I started to add finger support to Rogallo, I realised that this wasn't as helpful as I'd like as it meant I couldn't use it to actually check for a valid URI. It would be more useful to have the class be strict about only being passed finger: URIs.

So now, the first two examples give an error.

>>> FingerURI("davep")
port79.exceptions.URIError: Invalid URI scheme: ''. Expected 'finger'
>>> FingerURI("davep@example.com")
port79.exceptions.URIError: Invalid URI scheme: ''. Expected 'finger'

Instead, if you want the more relaxed approach, you should use the from_string method.

>>> FingerURI.from_string("davep")
FingerURI('finger://davep/')
>>> FingerURI.from_string("davep@example.com")
FingerURI('finger://example.com/davep')

With this change I can confidently use FingerURI to test if any given input is an actual finger URI, and this also makes it work in a similar way to GeminiURI in Wasat.

I woke up this morning to find that EE had sent me an email at around 00:30 last night.

We're sorry we didn't stick to our appointment or give you 24 hours' notice that we couldn't make it.

We've added a £32.31 credit to your next bill to try and make up for it.

You don't need to do anything, we'll add it automatically.

If you have any questions, please visit our help page.

And then at 08:17 this morning, I got an SMS:

Hi from EE.

We're sorry for not sticking to our appointment or giving you 24 hours' notice that we couldn't make it. We've added a credit of 32.31 GBP to your next bill. You don't need to do anything, but please go to ee.co.uk/go/compensation if you have any questions. Thanks.

Which is kind of weird, because I remember someone turning up yesterday, and my broadband speed is now 935/107 Mbps at the router (vs. the 35/2.7 it was at the start of yesterday). Perhaps it's their way of saying sorry for the failure to deliver the other day? Who can tell though, it doesn't actually say when and why.

The day after the last failed attempt to install fibre, I got a follow-up message from Openreach, pretty much not telling me anything I didn't already know:

We came to see if we can connect your property to our Full Fibre network yesterday.

The good news is we can, but the engineer found that the existing network connection point wasn't suitable for private land's underground connection, so we need to plan a new way to bring the fibre cable to your home, which may also require a specialist engineer for a flat roof connection.

We're really sorry for the delay, but we're on it and will update you again in the next 10 days (we're usually much quicker).

We promise Full Fibre's worth the wait. It's the UK's most reliable broadband technology.

The flat roof thing was... interesting, but okay, I'm sure they know what they're doing and that it's some automated system with a restricted set of outcomes.

Skip forward one day and I get an SMS out of the blue:

Hi, it's Openreach on behalf of EE/BT.

Sorry we missed you.

Book a new date for your Full Fibre installation here: [removed]

The "Sorry we missed you" was very odd. They didn't miss me. I saw them two days earlier. But, again, okay... I followed the link and it also seemed to be written as if one of us had missed an appointment and I needed to pick another day. Anyway, I ignored what it said and just used the date picker to pick the next available day (which was today: as in the day I'm writing this).

Fast forward to today and there's a knock on the door at around 08:30. Around two hours later, and this is what I was seeing:

To be clear: this isn't the actual speed of the connection. This was a quick test from my Mac, in my office, via the Wi-Fi connection. I don't currently have a Mac or PC wired into the router so can't measure the full speed. Testing on the router itself, it's much closer to 943Mbps/100Mbps. But, yeah, I'm good. I finally have full fibre again!

There was an immediate downside though. Once it was all set up, with the new router (which I swapped to as it has Wi-Fi 6, so why not?), I noticed that the ping times between my Macs were all over the place; this was also noticeable in that the ssh connections were so jittery to the point of being almost unusable.

Bugger.

So I did a bunch of digging online and, without getting too deeply into it (because I'm not a networking guy): the problem is AirDrop/Sidecar. They don't play well with a Wi-Fi 6 connection, so do stuff in the background that causes your ping times to be all over the place.

The solution? Turn this off for the Wi-Fi connection on the affected Macs:

I can't find anything that suggests I'm going to regret doing this for the couple of Macs in my office, and for my MacBook Air, and having done it, the performance is fine again.

This is why I avoid anything to do with networking: it always seems like if you improve one thing, it degrades some other thing, and it's only ever fixed by remembering to tweak some reasonably obscure setting somewhere on some particular item of hardware.

Still... I HAVE FULL FIBRE AGAIN!

Finally, I can think about doing the odd stream again.

While I'm having a moment of calling code stable, I've bumped Wasat to v1.0.0 as well. There's no actual difference here when compared to the last release, other than the development status classifier in the PyPI metadata and the version number.

The library feels pretty stable at this point. I've been using Rogallo every day for a wee while now and I've seen no surprising problems.