Vim is actually quite easy to build from source with a
make install. You can edit
src/Makefileto enable features and custom language extensions. Turns out, I hadn’t scrolled through that file in a while, since version 8.0.1295 comes with an interesting addition – the compilation flag
Running the editor with a
--servernameparameter allows remote connections from a different instance using command-line flags or function calls. I’ve been using this functionality to build a custom testing framework in Ruby, but you have to knowingly launch it with that flag. Now, each instance can be available to connect with by default.
It’s not necessary, exactly – you could always make yourself a shell alias like
alias vim="vim --servername VIM-$RANDOM". But the discovery gave me an idea of how to remove a tiny bit of friction from my Rust workflow, and I might end up using the same technique in the future. Read on to learn how to send your build output to a Vim instance for easier processing.
For the last two years, I’ve been one of the organizers of an elective Rust course in Sofia University. Last semester, one of the homework assignments we came up with was to build several kinds of “logger” structs with buffering, multiple outputs, and with tagged logging. (The full assignment is here, but all the instructions are in Bulgarian.)
It was a pretty good exercise on using
RefCellthat wasn’t a linked list or a similar data structure. The goal was to ensure a logger can be cloned, with the copies sharing both the same buffer and output.
Testing the code seemed easy at first glance, but I did run into a bit of a problem when simulating loggers printing to “the screen”. The solution is not exactly complicated, but I think it’s a good pattern to share.
I recently wrote a tool to manipulate images embedded in mp3 tags: id3-image. To be able to make changes to the code with confidence, I needed tests. Rust comes with the very sensible
Writetrait that could have allowed me to mock any IO (a blog post for another day), but in this case, the project relied on the excellent id3 crate, so I wasn’t doing any file-writing myself.
Instead, I wanted to have an actual mp3 file and an actual image, apply my code to them, and inspect the results. This generally isn’t difficult to do, but I ran into a few unexpected gotchas, so I’ll summarize how I ended up implementing it.