Breaking things one pointer at a time

Adding dark mode to my blog

Being the typical zoomer that I am, dark mode has become an essential component of my digital experience. Over the many years of late-night gaming and the early onset of myopia from staring at too many screens, the blinding effect of the white backgrounds eventually pushed me into more and more dark-themed applications. I'm writing this blog post on a dark-themed computer, running a dark-themed terminal emulator running a dark-themed neovim instance. Even once this post is finished, I'll double check it on my dark-themed browser, before swapping to my dark-themed phone and making sure that things look fine on there.

My love of dark modes has extended into other applications as well. GitHub has its dark-mode set on by default for me, as does Sourcehut and YouTube. DuckDuckGo because my primary search engine partly because it gave me easy access to a dark-mode that I could never get working on Google. I stopped using the Gmail web client last year in favour of terminal-based alternatives partly because I could never get dark-mode to work properly on it.

All of this, and until a little over a week ago, I only had a light theme on my blog. Scandalous.

The theme that I use for this site (which when I finally publish it will be able to be found here) is based on insipx's Ergo theme, which is in turn based on svbtle. It's a lovely minimal theme, but unfortunately it only has a light theme.

As mentioned above, there are a number of websites which I use with dark-mode enabled, and surely I could just pick one and do what they do? Well unfortunately for me (but not unfortunately for this post), most of them require local storage of some form in order to retain your mode between sessions. Changed computers or browsers? That's a revision back to the realm of light-mode for you. Opened up a private browsing window? Better hope they've somehow tracked you through there before your eyes begin to burn.

Even some of my favourite blogs (such as fasterthanlime) which have a dark-mode use local storage to activate it, and it can extremely temperamental between sessions.

Fortunately I can continue to avoid JavaScript on my website thanks to the @media(prefers-color-scheme) feature. As stated on the MSDN, the prefers-color-scheme media feature can be used to detect if the user has requested a light or dark colour scheme, and allows you to override CSS variables accordingly.

This is actually what Sourcehut does to set its colour scheme, and as such I've based my dark theme on theirs. I think the blue accent is much more suited to a dark background than red, and vice-versa for a light background.

So, if you are currently seeing this in what looks like dark-mode and would like to see what it looks like in light-mode or vice-versa, it should change to the other dynamically when you change your device theme. As for me, I'm going to never look at the light theme of my website again, and pray that it never breaks.


On the experience of good audio

I recently started listening to music with my Sennheiser 6XXs after around six months of using nothing but earbuds (Sennheiser Momentums and Momentum True Wirelesses).

Now, I love the sound on my earbuds, especially compared to the many other earbuds that I've tried, something about Sennheiser's audio engineering just works particularly well for my musical tastes. I had found, however, that as time went on I used my earbuds less and less, and was generally more happy to listen to music and podcasts using nothing but the speakers of the device they're playing on. Part of the reason for this is that my Pixel 5 doesn't have a headphone jack (although I do have wireless earbuds) and my experience of bluetooth audio on my desktop and laptop (regardless of operating system) has left a lot to be desired, so the easiest common ground was just the speakers.

Since I've restarted my use of my Sennheiser 6XXs, I've spent the days doing nothing but listening to music for the sake of the audio experience, which I never really did with the various earbuds. The songs I'm listening to I have heard before, but with the better audio quality and dynamic range comes a whole new range of experience that I simply didn't have access to before - and its hard to quantify how much better it is.

I think that's part of the reason that "audio quality" is so difficult to sell - it's an almost unquantifiable metric that is both incredibly subjective and extremely expensive. High quality audio gear sells for thousands of dollars, and the curve of how much more needs to be invested for a substantial difference is such that gear that is "good enough" sells for less than a hundred dollars. How on earth could you convince anyone that hasn't already invested into audio gear that it is worth it?

I'm certainly going to try to start using my headphones more, and that's also going to involve a level of investment and care from me. My house gets extremely dusty (especially in the summer) - which is part of the reason that I put my headphones away in the first place - and so I'll have to figure out a way to make using them both easy and largely dust proof.


Moving to zsh

I recently transitioned away from the ion shell to zsh, and I figured it might be a good idea to float some of the advantages and disadvantages that I've found during this time.


  1. Mostly POSIX compliant.
    I'll touch on this more later, but in general the ability have portable scripts that work across systems and shells has been incredibly useful - especially as I expand the number of machines I use and prepare to start working after finishing my masters. For those wondering, ion is explicitly not POSIX compliant.
  2. I can reclaim the @ symbol and not worry as much about quoting ssh.
    This is a part of ion's lack of POSIX compliance, and it claims the @ sigil for use in array specific functions and variables. I've generally found throughout my use of ion that I use array variables much less than I do the @ sigil, and getting it back for ssh, git and the like has been a major boon.
    (It isn't so much that I'm against arrays per say, just that I'd prefer that it somehow reused a symbol that's already typically used by shells instead of nomming another character)
  3. Its much easier to get setup on new computers.
    I've just put Alpine Linux on a Raspberry Pi 2B, and have begun migrating some recurring tasks to its crontab. Last time I checked, ion still had some issues building on arm-based platforms, so unfortunately I can't quite port my dotfiles to it. I've also recently completed my masters and will begin working in the middle of January. Knowing the company that I'm working for, there's a chance that I might be getting one of the new-fangled Apple Silicon Macs, and at the time of writing this post, there are still issues with porting even just the Rust compiler to the new platform.
  4. Completion.
    Oh boy this is a big one. ion "has" completion, in that you can tab complete files and commands. What it doesn't have - however - is the ability to tab-complete arguments (which can be an absolute life-saver) nor other more specific completions such as man pages.


  1. Slower start times.
    I open a lot of shell prompts - anyone who basically lives in the terminal and incessantly uses tmux does. Something that I've definitely noticed is that the time it takes to open a new window or prompt is much lower with ion than it is with zsh - and indeed hyperfine backs this up. An invocation of hyperfine 'zsh -i -c ". ~/.zshrc; exit"' takes around 70ms (with approximately half of that being completion pre-processing), whilst running hyperfine 'ion -i -c "source ~/.config/ion/initrc; exit"' only takes around 20ms. And that's despite my ion config doing more than zsh's as well as not being as well optimised.
  2. Visible history completion.
    One of my favourite features of ion is that (similar to fish) it shows you the most recent matching command in your prompt. As of yet, I haven't been able to figure out a way enable a similar behaviour in zsh without loading an extension module, which has me weary due to the potential additional startup latency I might end up with.


I think I'm probably going to stick with zsh until I find a better shell to move to. Something like mrsh seems like a great idea of something to move to eventually, especially as dash will likely never implement any form of completion, whilst imrsh names good completion as one of its goals.

Interestingly, one of ion's major advertised features - its inbuilt data structures - are actually something that I've found myself rarely using, especially whilst actually at the shell. I usually find that should a hashmap or the like be required, then that script should probably be converted to a language like Python, even if only for clarity and the rich inbuilt libraries.


The different approaches between `emacs` and `vim` packages

I recently tried using emacs for the first time in many years (the last time I used emacs was back in early 2017, and I moved to using vim later that year). Many of my colleagues at my last internship use emacs - there was even an internal minor mode for editing and using many of the internal tools - and a number of friends at university are also emacs evangelists, so I thought that it'd be a good idea to re-acquaint myself with the editor that I left behind.

Long story short - I've decided to stick with neovim. There's actually a bunch of reasons why (which I can probably go into at a later date), but my brief foray back into the world of emacs showed me an interesting difference in philosophy between emacs and vim packages.

As someone who (of course) wants to use vim bindings in every text editor that I use, I of course installed evil-mode, the vim compatibility layer for emacs. This went along quite swimmingly until I had to install other packages, all because they all automatically overrode keybinds.

This was a pattern that tended to find throughout my emacs experience. Packages create their own major or minor mode, and then provide a number of key-binds within that mode to interface with its functionality - which can cause a lot of problems for me when I've remapped a good number of the keys because I don't use a QWERTY keyboard.

It's become like a game for me. See how many plugins I can find that all try to override the same key-bind.

In my experience, vim packages have the exact opposite approach - although I will fully admit to not using very many packages. coc.nvim, for example, doesn't set any keybinds and instead requires the user to assign their own binds to the functions that it provides. FZF does exactly the same thing, as does vista.vim.

This has actually been really surprising to me, as I would have likely expected the exact opposite. I often hear emacs talked about as being an "elisp interpreter with an editor attached" - which to me suggests that the primary focus of emacs would be on elisp functions - whereas vim's major selling point is its excellent keybindings.

I think that if emacs packages had taken a similar approach to what vim packages seem to - that I'd have expected them to take - then I'd almost certainly switch to emacs for the additional flexibility of having the power of lisp at my fingertips. As it is, however, it would take far too much work every time I install a package for me to want to move.


Tracking myself

Partly inspired by Julian Lehr's quantified self, I'm planning on trying to track myself. I don't expect that I'll actually start on this for a while, as there are a number of tools I have to figure out before I can properly get into the swing of things, but I figured that it'd be worth writing down my reasons why I want to do this. In future weeks, I'll cover how I'm building the tools to let me track myself.

I'm generally a pretty privacy-focused person. Any applications that I use always have telemetry turned off, my social media is basically whisper quiet unless its via private messages, and I even borrowed a laptop from the university so I wouldn't have to use exam software that required root privileges on my own hardware.
Tracking myself - and posting it on this blog like Julian Lehr does - seems to run pretty contrary to all sorts of privacy principles. So why on earth would I want to do it?

I've always sort of considered myself a numbers guy. In primary school (in Australia, that's ages 4-12), I was the "math guy" in the class, and had by far the best marks in maths in my school (although I don't think I even made the top quartile in high school), and have always found maths that I can apply to be fun and interesting. It's part of the reason that I got into programming in the first place.

I'm also generally well convinced by numbers that are put before me in order to inspire some continued positive action. Watching the numbers on the weights at the gym go up, how good I felt as I ran 5km slightly faster than before, and my weight go down (even if only a bit) has encouraged me to regularly exercise far more than the nebulas "it's good for you" that my parents always told me throughout my teenage years.

As such, I am somewhat convinced that tracking myself - and watching trends for various metrics of how my time is spent - will help me be able to narrow down and improve things that in my life. Perhaps I can see if I've spent too long on a particular weight at the gym, and should go to the next weight up. Maybe I can spot transport routes that would be slightly more efficient than what I currently have. I could even find that I spend half my time doing nothing useful at all, and thus need to come up with strategies to improve productivity.

There's an extent to which doing this is good for my privacy as well. By tracking myself, I will be able to get a better understanding of what sort of data companies have on me. My smart-watch (a Garmin VivoActive 4) will probably be used for most of the data, and frankly the amount of data that it can/does have on me is slightly terrifying - especially now that I've gone through what I can get from Garmin's API. I'll be able to go digging to see what Amazon has on me (Kindle/Audible), what Google has figured out (Android/Google Assistant), and how Spotify could figure me out. In the process of tracking myself, I'll become more aware of how others can track me too.

In addition, as long as my data isn't too fine-grained, privacy shouldn't be too much of an issue. I don't plan on writing detailed logs of exactly where I've been - if my house shows up anywhere, then you know that my data collection has gone too far. I don't even plan on sharing any GPS-type metrics at all, save what city I'm in.

I imagine that it might take me some time to be able to even get the right sort of data for any useful analysis, and whilst I don't really know what I might find out, but I'm excited to see!