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.

On Wednesday, May 8, 2019, South Africans had the opportunity to elect their leaders for the coming five years by taking part in the 2019 general election. Of the 26727921 registered voters, 17671616 made their way to the ballots. Of these, 17436144 citizens managed to submit a valid vote. These 17M+ votes were then tallied up to determine how the 400 parliamentary seats would be allocated to each of the qualifying parties.

This post documents my measurements of the slow-down caused by the Windows 10 (1903) anti-virus real-time protection of Hugo static website builds, both with and without the Windows Subsystem for Linux (WSL). Methods I measured the re-generation of a site with about 2700 pages in total (my personal blog) using Hugo v0.55.5 on this ThinkPad X1 Extreme (i7 8750H, 32GB RAM, Samsung Evo Plus 1TB SSD) with Windows 10 1903, aka the May 2019 update.

On macOS, links of the form message://message-id are by default supported by the system. Using a tool such as org-mac-link, it is straight-forward to link directly to relevant emails from Orgmode tasks and notes. It does not matter if you have moved the mail around. When you open the link from Orgmode, the relevant email is instantly shown in Mac mail. Fortunately, similar functionality can be configured on Windows and Linux using the Thunderbird mail client, an add-on called ThunderLink, and a touch of Emacs Lisp.