LinLog

Today we experienced a somewhat significant event: my son beat his very first Nintendo Switch game.  It was Splatoon 3, which he got for Christmas.  He's been playing it since then and just this morning he finally beat the final boss for the first time.

I've never played the game, so I have no idea how difficult it actually is.  However, several times I've seen my son get frustrated and upset because he was having trouble with it.  So it's a life-lesson - a small one, but a lesson nonetheless.  He struggled, he stuck with it, and eventually persevered.  Games can be very useful for that sort of thing.

My son was very happy to finally beat the game.  He called me in to watch the end and called his grandmother afterward to tell her about it.  It was really nice to see him to excited and to be there with him to share this small triumph.  Call it one of the joys of parenthood.

This is probably a big "duh" for anyone who's used it before, but Vim's macro recording is pretty handy.  It's one of those things I've been vaguely aware of for a long time, but never actually used before.  Until now, I really only ever recorded a macro by accident.

But the other night I was playing around with my attempt to learn Go by writing a NES emulator.  I'm working from a demo of writing one in Rust, which recommends having highly comprehensive unit tests, so that's what I'm trying to do.  The problem I'm running into is that this results in lots of repetitive test cases.  The individual test cases are short, usually six to ten lines, and take the form of a struct defining the processor state and expectations.  The thing is, there are a lot of them.  By that, I mean that so far I've implemented 20 of around 150 opcodes and my unit test file is already pushing 1000 lines, compared to about 250 lines of production code.

Now, a 4:1 test to prod ratio isn't necessarily a bad thing, but it does seem a little high.  And the tests are all very similar, so they're kind of hard to read and navigate - unless you know the exact term to search for, they all just blend together.  So I really wanted to condense them down, preferably to one line per test case.  So I finally decided to make a few functions to extract the common stuff into a template so that I can condense all those structs down into one-liners.  Great!  But I already have 1000 lines of code to update.  Not so great.

Enter the Vim macro reorder.  For each opcode, a wrote a function to create the test template.  Now I had to take the existing structs and convert those into function calls.  Unfortunately, this was too complex for a simple substitution and it was just too tedious to do that many by hand.  However, the exact same series of steps could be repeated for each test case, so I decided to look up that macro recorder that I've been accidentally turning on for years.

Turns out it's super simple.  You just start recording by using "q" with a register name (e.g. "qa") in command mode, do a bunch of stuff, and then run "q" again to stop.  Then you can execute the macro with "@" and the name, e.g. "@a" and repeat that with "@@".  By itself, this is not terribly remarkable.  But with Vim movements and actions, it's really easy to make a macro that performs a complex manipulation on structurally identical blocks of text.  So I was literally able to start recording, just do the manipulation like I normally would, and then stop recording, leaving me with a macro that works perfectly with basically zero extra work.

Like I said, nothing really new or ground-breaking here.  Just discovering one of those handy features that I've never really used before.  But now I know how to take advantage of that for future use.