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 two files in the .vscode sub-directory of your source directory, and all of the above will be done.
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 .
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.