Background. On Windows, I run Emacs on WSL 1 whilst displaying to Windows via the X410 X-Server. This is currently the best compromise if one wants to interoperate with the NTFS side, at least until the WSL 2 developers manage to fix up its current cross-OS IO performance issues. As part of this setup, I have written a small xdg-open replacement in Python which does path translation. This enables me to open any links from Emacs, running on WSL 1, using the relevant Windows file handler, no matter whether the file finds itself on the Windows or the WSL side of the world.

Previously I wrote how to get the WlzIIPSrv large image server running on webfaction, using lighttpd. Fast-forward 2.5 years, and I was busy porting the whole site (again), this time from webfaction (acquired by godaddy, who are planning to kill the great webfaction product), along with all of my other websites (including this one that you’re reading), to a fast, self-managed Hetzner VPS in Nuremberg. I needed to get that exact same WlzIIPSrv large image slice server fastcgi running, but this time behind nginx and preferably without lighttpd.

Background I recently joined the Windows Insider Program, on the slow ring, to be able to test a development version of the soon-to-be-released Windows Subsystem for Linux, version 2, henceforth WSL 2. Microsoft is doing fantastic work integrating Linux with their Windows operating system. I find it personally quite useful being able to do native Linux development on the Windows partition of my ThinkPad, whilst still having access to all of the native Windows applications that I sometimes need to use.

TL;DR. In this post, I propose bending the format=flowed RFC by allowing lines up to the SMTP limit of 998 characters, in order to improve the plaintext reading experience for users of non-compliant email clients and services, such as GMail, FastMail, Outlook and others. Background. The format=flowed plaintext email convention described in RFC3676 is an elegant method whereby plaintext emails can be prepared in such a way so that they are wrapped correctly on older email clients, but they can also be reflowed by modern clients supporting that part of the standard.

As I mentioned in a previous blog post, I switched from a 2017 15" MacBook Pro to a Thinkpad X1 Extreme in April of this year. Although I’m still using Windows on this machine in order to see what all the fuss is about (BTW, WSL is amazing), the Linux itch could not be ignored anymore. What makes this laptop slightly more challenging than some of my previous Linux laptop and Optimus (dynamically switching graphics) adventures, is that in this case the the NVIDIA dGPU is hard-wired to the external outputs (HDMI and and displayport over thunderbolt).

As I recently changed my imap downloading tool choice from offlineimap to mbsync, and because the word on the street (where with “street” I mean “random discussion forums on the internet”) is that mbsync is generally faster than offlineimap, I wanted to run a small test to measure the difference. Methods For this test, I re-synchronized the exact same subset of my IMAP folders, totalling about 11000 emails, which together occupy about 2GB on disc.

These days I’m running mu4e, the mail programme that runs on the Emacs operating system (the one with the terrible editor), on the Windows Subsystem for Linux (WSL). (Previously, see my other mu4e posts, I was using it on Linux or macOS.) I have also switched from offlineimap to isync’s mbsync for no other reason than it was time to try something new. In addition, and this is the topic of this post, I’ve switched from nullmailer to Emacs’s built-in smtp and smtp queue functionality for email delivery, because I now prefer the idea of having a second chance to evaluate whether an email should really go out or not.