Last week Microsoft had to deal with some criticism, because they announced “Recall”, a new feature, available only on their new Copilot+ AI-enabled laptops, that makes regular screenshots as the computer is used and uses on-device models to generate descriptions of these images that can be stored in a database (sqlite of course) and later searched, so that a user can effectively go back in time to find almost anything. They have stated that everything happens and is stored on-device, and that the whole feature can be easily disabled.

LTTB, or Largest-Triangle-Three-Buckets, is a fantastic little algorithm that you can use for the visual downsampling of timeseries data.

Let’s say your user is viewing a line chart of some timeseries data. The time-period they have selected contains 50000 points, but their display is only 4K so they have a maximum of 3840 pixels available horizontally. With LTTB, we can automatically select the 3840 or fewer points from those 50000 points that will produce a line graph which is visually very similar to what they would see if they were to try and render all 50000 points.

Introduction

Just the other weekend, I had to exchange contact details using quite primitive means with a fantastic new friend after a deeply enjoyable hike up Table Mountain via the India Venster route.

We could not get the flashy new iPhone-bump method to work. Although the animation triggered with each bump, no contact details were exchanged, a failure which caused the Android user at the table much mirth.

That incident drove me to retrieve some old Python code I had written to try out Segno, a QRCode generator library for Python, and to test out the recently announced WASM capability of the new Marimo reactive Python notebook.

Background

I was curious whether it would in theory be possible to use the docx format as a storage format for markdown documents with their associated image files, and in addition, to support the light editing of the docx file directly.

In other words, the primary authoring modality would be via markdown and attachments, because this works really well for software documentation, but storage and sharing would happen via docx files, additinonally supporting the occasional direct editing of that docx without breaking the normal markdown workflow.

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.