The blurb

Below is the emacs-lisp code I’ve evolved over the years to setup reasonable font sizes on all the machines where I use Emacs.

The main goal is to get the physical / apparent size of the font, in millimetres, to be more similar across all displays and display systems (Different screens across macOS, Windows with and without display scaling, WSL). This sounds like it should be easy, but setting font point size to the same number is in fact interpreted differently on various display systems.

This morning while working on my AoC submission, I wondered what the simplest procedure was for sharing a minimal setup for editing Python in Visual Studio Code using ruff for formatting, linting and import sorting, and doing all of that automatically on save.

It turns out that you can just store the following extensions.json and settings.json in the .vscode sub-directory of your source directory, and all of the above will be done. As a bonus, you can use the ruff.toml example below to customise your ruff setup.

Install and configure hunspell

Imagine this: For intricate reasons, you have decided to get your Emacs setup working on Windows as well, although you have a perfectly fine and working WSL2 configuration.

You’re surprised by how well this goes (winget install GNU.Emacs FTW!), until you decide to setup the hunspell spell checker…

It starts pretty well, when you are able to install hunspell with a simple winget install FSFhu.Hunspell, after which you download a set of English dictionaries from the LibreOffice extension, and then set your DICPATH environment variable to point to the directory containing all of the unpacked .aff and .dic files.

This is a small variation of the 2019 post on linking to emails from Org mode using Thunderbird, where instead we show how to open the message:// links with mu4e if active, or the fastmail web-app if it is not.

You might remember that message://msg-id-here links represent one of the better ways to link to emails from your PKM systems.

Code

Below is the code. Let me know in the comments if you have any questions.

Introduction

Python’s ThreadPoolExecutor’s context manager is a really neat way to run a bunch of (I/O) work in a thread pool, and then clean everything up when the context is exited.

Something like this:

1
2
3

with ThreadPoolExecutor() as executor:
    for i in range(N):
        executor.submit(my_function, arg1, arg2)

Where did my tasks go, attempt 1

Recently at work however, I had to debug a case where it appeared that it would discard tasks that had been submitted later.

Background

For years and years now, I keep all of my work, including my checked-out source code, in some form of file synchronization system.

The advantages of having all of your files always up to date on all of the comptuters you work on are considerable.

More practically, I often get up from my work computer, and then continue on my laptop, or on my home computer, without having to think about it, and especially without having to abuse git commits purely to be able to transfer to another machine.

Background

My notes database consists primarily of Emacs Org mode files, interspersed with a small number of markdown files, some of them from previous note-taking systems (for example, I went through a Gollum stage early in 2014, according to my notes then), and some of them for easier mobile consumption and production.

I recently discovered nobiot’s md-roam Emacs package which makes it possible for these markdown files to show up (in sheep’s clothes, as it were) amongst all of my usual org-roam nodes.