Journal: Rust DocDB; VS Code Helix keymap

A couple of notes for my future self, to remember some things, and when I started some other things.

• First, a decision to use Rust for my Build Your Own Database Project, or, at least, a hankering to take an opportunity to learn more Rust.
• Second, a short journey of discovery into whether I’d be able to keep using a Helix-like workflow in VS Code, if I ever had to go back to that editor.

Rust DocDB

In my Build Your Own Database Index series, I’ve been building a database index in Go. But, as I noted in Mini Project: mdanchored, I’ve been wanting to get better at Rust.

I knew that I’d have to learn database stuff for BYODI, however, so I chose to start the project with Go because I already knew Go. It meant I’d not have to be learning two things at once: Rust and database stuff. But now I’ve got some of the database stuff down in code, I find myself wanting to go back to learning Rust. So I’ve decided to have a go at a port of my Go code into Rust. I haven’t done much so far, but I think it’s a good next step in my Rust journey. I’ve worked out how a lot of it needs to work, but I think it’ll exercise some less trivial Rust skills.

Of course, I’m still going to make use of an existing key-value store. This time I’ve settled on sled, which seems to be a mature, well-made library originally based on Bw-Trees, but with improvements made since.

Anyway, the BYODI series is probably going to go quiet while I make this port, unless there are any interesting changes along the way. One change in particular that I might make is to update indexes alongside primary data updates, to avoid maintaining the forward index. We’ll see.

The code is on GitHub at mikerhodes/rust-docdb. There’s not much of it yet!

VS Code Helix Keymap

I’m still very happy with Helix. But VS Code has a pretty massive ecosystem of tools, and I figure that at some point I may have to venture back there. Also, workplaces have started to standardise on it. So anyway, I decided to take a look around at whether I’d have to drop my Helix workflow if I went to work in VS Code. I found that there’s a Kakoune extension called Dance. Kakoune inspired Helix’s workflow, but Helix has made a bunch of changes to the way that Kakoune’s flow works. When I tried Dance on its own, it was confusing.

However, many of Helix’s changes are around UX rather than core mechanics. For example, changes to Kakoune’s hotkeys and adding more affordances for those coming from Vim. So, rather funkily, it’s possible to use the core text manipulation primitives created for Dance, but reconfigure them to allow editing in a Helix-like way.

To do this, you need to make extensive changes to your settings and keybindings files in VS Code after installing the Dance extension. These override Dance’s settings and keybindings to alter the extension in ways that cause VS Code to work like Helix rather than Kakoune. And it works rather well.

To make these changes yourself, visit this GitHub comment and copy the changes from the linked settings.json and keybindings.json into your own VS Code configuration.

If your existing settings and key-binding customisations are anything like mine, the copied JSON will consist of about four hundred times more JSON than you had originally. It’s a bit weird, but it works just great. I wonder whether the changes could be folded into their own mini-extension to keep them out the way a bit, but I’m not au fait enough with VS Code to try that out. Anyway, they make VS Code work enough like Helix for my purposes.

This fixes one of the main fears I had for my growing Helix skills: that I’d have to go back to Vim if I wanted a consistent experience across VS Code and my terminal editor. Thankfully, it seems like that isn’t the case. Phew!