Honing the Tools (I) - Introduction

I have recently started feeling disenchanted with my work setup. I have mostly been using VS Code to interact with all the technologies I use at work: mostly writing different flavors of SQL (BigQuery, Snowflake) as well as Python code in a vast array of situations and technologies: one-shot scripts, notebooks, services, Docker containers, etc. For most of those uses, VS Code proved to be a good companion: if not supported natively, plenty of times, a plugin was enough to fulfill the missing pieces. Those plugins had different UIs, so I slowly started neglecting the shell, which became just a line to launch a fistful of commands from a tiny window inside the editor. At some point, I started feeling deeply alienated using my own tools: the configuration options were very limited, even for some things that were really crucial. Depending on plugins on VS Code proved tricky, since some of them were maintained by companies that constantly prompted me to log in with a different account to sync with their own tools. Out of this frustration, I started migrating back to the CLI, and trying to find a modern and comfortable set of tools for it.

This series are born after this feeling: I want to have a comprehensive understanding of my tools, bit by bit, to be able to compose and configure them properly. These posts will be a logbook of that journey, hopefully being useful for someone sailing similar waters. However, some background is needed to understand the current state of everything.

Regretting the change

Some time ago, I wrote about how I shifted from my Emacs blogging workflow to a simpler, more generic approach. This happened roughly two years ago and, in the meantime, the same feeling started developing in different workflows I had worked out: my Emacs configuration shifted from my main work tool to a high-maintenance hobby, and my dotfiles started rotting once I shifted my working OS from NixOS to macOS. I started using tools that allowed me to be productive out-of-the-box (the clearest example being VS Code), and discovered that I could achieve most of my productivity without having to worry about my (several) configurations.

This was an illumination until I slowly noticed how I had run myself into a corner: most of the tools (or the state I used them in) did not allow me to achieve full ergonomy. I tried twisting and plugging together different things that were clearly not planned for it, which only led to wasting time and frustration. I was stuck in a suboptimal state, with nothing to do about it: I tried removing some complexity (for example, some VS Code plugins), only to discover that the friction was still there.

A joy found again

Some weeks ago, I discovered wezterm, a terminal emulator. It is written in Rust, has GPU acceleration and focuses on simplicity and snappiness. Not only that, but it provides a Lua configuration interface with some very interesting options. It immediately caught my eye: by default I use iTerm 2, not because I’m exactly fond of it but because everything else felt worse: I have tried alacritty and kitty (which don’t feel as good in macOS), some experimental tools like Warp or Tabby (which felt sluggish and baroque, adding a lot of features I was not using), and the default Terminal and iTerm (which felt ok but are absolutely atrocious to configure) - I found none of those tools convincing. I spent an evening tweaking wezterm and in a couple of hours I had the best terminal emulator by far.

Sometimes, that kickstarting spark is all it’s needed. Suddenly, I wanted to use the shell again. I used zsh in a messy configuration that certainly sparked no joy, so using some old notes I refreshed my knowledge about different shells. Decided to try fish again after roughly 6-7 years, and was deeply impressed by how easy it was, and how much better the fish language was compared to bash. I cloned a half-baked NeoVim configuration and started playing around, and found everything so much better than the last time I tried, to use it with tmux (wezterm provides some very basic multiplexing capabilities natively).

Then and there, I decided to start shifting again to the “hard” tools. No more suboptimal workflows and resignation on plugins that were not good for me; I wanted to take control of my tools once again. The thing is, I needed a plan. Last time I tried it did not go as well, even though I was still in college with plenty of time to tweak eveaything.

The plan

As I said, I’m unfortunately not in my college days anymore, when I had almost unlimited time to tinker with tools in the cafeteria. Now, I expect to take a more conservative approach to be playful with my options but not lose my time: I don’t want to crash again into a configuring spiral and run out of a productive environment. To do so, I plan to do it with the following approach:

• No drastic changes: I will keep on using my current tools (VS Code et al.) by default, except for certain tasks for which I feel I can be as productive with the configuration I have at any point in time. Therefore, writing some basic JavaScript is a good candidate to experiment with new tools, while using a debugger for a Python web server in a Docker container may be one of the last use cases to be ported. This will also favor atomic tools, that substitute one certain plugin or workflow in my current setup.
• A joy to configure: As much as I still love Emacs Lisp, I don’t think I can keep up with learning a new paradigm nowadays if the tools require it for me to configure them. The tools I have mentioned already have great configuration languages: fish has its own iteration on a shell scripting language (much comfier than bash, which is not setting a high standard) and both nvim and wezterm use Lua, which strikes the perfect balance between simplicity and familiarity for me. I don’t want any more JSON configuration settings for my editor, thank you very much.
• Tools that focus on stability, safety, modern UI and/or snappiness. Not even the three of them, but they at least have some interest in not being bloated or sluggish. This mostly discards some apps I have used based on Electron (VS Code is the only app built on it that was not noticeably slower). CLI tools these days usually provide some interest in achieving a fair subset of these qualities.

What’s next

In future entries of this Honing the Tools series, I expect each post to be a deep dive into a tool (or an aspect of a tool - I’m certain a single post is not going to be enough for NeoVim) and its manual, taking notes and checking some of the configuration options. That way, I will take some notes while browsing these options, which may be useful for other users and certainly productive for me. The order will be more or less organic, starting with the tools I am already comfortable enough using and leaving more extensive topics for future entries.