I have decided to open up a GitHub sponsor page. Recently I released the Neovim plugin nvim-ts-rainbow2, which has garnered a lot of stars, so I figured I might as well try this sponsor thing. There is also a Monero wallet for those who prefer to forgo the middle-man.
I have written a small Python script which patches the game files of Anno 1503 to run at higher resolutions. There is already a widescreen patch out there ready to use, so why create a patcher? Download links die, knowledge gets forgotten and people lose interest and move on. Without preservation of knowledge the patch will be lost and impossible to reproduce without trial and error all over again. My patcher exists both to be useful, and as executable documentation for posterity. There is also the possibility that if you patch the DLL file that came with your own game instead of using someone else’s it might run more stable (not all builds of the game are identical), but that’s just a blind guess.
Two months in the making, it is time to finally release my new Neovim plugin officially: nvim-ts-rainbow2 (GitHub mirror). This plugin uses Neovim’s built-in Tree-sitter support to add alternating highlighting to delimiters. This is usually known as “rainbow parentheses”, but thanks to Tree-sitter we are not limited to parentheses, we can match any kind of delimiter, such as tags in HTML or begin/end blocks in some programming languages.
My current terminal emulator is Alacritty. One thing I would like is a way to change the colours while the terminal is running. The only way to do so is the edit the configuration file, but doing so by hand can be annoying. There are some scripts out there that let you do it automatically, but all that I have found rely on bloated stuff like having Node.js installed. We can do better by using just what we already have on Unix out of the box.
Git is a decentralized version control system, meaning that there is no one superior repository. Every single copy of a Git repository is just as complete as any other. Of course we can pick one particular repository and declare it to be the one source of truth, the “upstream” repository. Usually this upstream repository is then hosted on some server, and if we are interested in openness and collaboration this server is part of a larger web service, called a “forge”. Out of these forges GitHub is perhaps the most popular one. Unfortunately this means if we are interested in contributions we have to make the GitHub repo our upstream and use its web services and web UI for our workflow. At least that is the common wisdom, but it does not have to be that way.
A while ago I announced my new pet project HSSG, the hackable static site generator. The final step of generating a web site is writing the actual files to the file system of the operating system. So far this has been a messy affair where information about file paths had to be dragged through the entire chain from start to finish. This was ugly, hard to maintain and it muddied the layers of abstraction. In this post I will explain how I brought order to HSSG through a file system abstraction.
The term “user-friendly” gets thrown around often, but what does it even mean to be “user-friendly”? Clearly we can say that something is more user-friendly the fewer defects it has. But beyond that? Is a GUI application more user-friendly than a text-based application? Is a lower learning curve more user-friendly than a steep learning curve? Is a product which has many features built-in more user friendly than a barebones product or an extensible product?
I am glad to announce a new Neovim plugin: nvim-cmp-vlime (GitHub mirror). It is a completion source for nvim-cmp which uses the Vlime plugin to fetch completion candidates from a running Common Lisp process. Vlime is a plugin similar to Slime for Emacs, it lets the editor communicate with a running Lisp process so we can evaluate code at runtime, debug, inspect values, and of course get auto-completion. In fact, Vlime uses the same Backend, Swank, as Slime, so the results should be equally good.
In June of this year I introduced my Common Lisp library cl-cmark (GitHub mirror), which implements parsing [CommonMark] documents and manipulating the resulting document tree. I have been hammering out the last kinks over the past weeks and I am now ready to call it done. Before I officially put the 1.0 stamp on it though I would like if a few more people could take a look at the library and give it a try.
In January 2019 I switched the static site generator for this website from Pelican to a custom one written in GNU Guile. Most (or all?) static site generators out there have an opinion on what a website should be made of. You might have full control over the layout and content of individual pages, but not so much over how the web site itself is composed. Writing my own static site generator freed me from these constraints. Now if I want to have sub-sites and multiple blogs I can do so. However, the custom generator was suffering from the same problem: it had one specific web site composition in mind, it just happened that this time it fit my needs. That is why I have created HSSG: the Hackable Static Site Generator.