Tag Archives: productivity

Work Style

Getting Started with Neovim

I spent some of grad school really getting into Vim. Then I shifted around, and most recently I’ve been using VSCode. A number of my colleagues (per screen-share demonstrations) seem to use some kind of neovim, but I’ve not really talked to anyone about it. I think I learned about neovim a while ago from Hacker news, so it’s been very lightly on my radar.

I like the general idea of the editor being something you get-in-and-get-out–vim’s original idea. I really tried to use Emacs as an OS a while ago, and I was never quite able to buy into that. Alon those lines, when I see various youtube videos on how to set up neovim, so many of them basically celebrate setting it up as an IDE. This suggests they don’t see the same “cost” to plugins that I do!

Cost of Plugins

Plugins add some functionality to neovim, but in turn increase the size of the cross-product-of-compatibility you have to worry about. If I have 30 plugins active when editing some source file, and suddenly neovim crashes, I have at least 31 things to consider investigating. I’d rather not! Even in the non-buggy case, when there is a plugin that I really like, to a degree I have to care about the compatibility of it with all the other plugins. This is true as things upgrade, or there’s some hotness (like a new plugin manager) that suddenly half the plugins want to move to, and half the plugins don’t. From what I can tell so far the plugins in neovim work hard to maintain compatibility, but that’s just it: it’s hard work!

Using “just” neovim doesn’t spare one from this, of course, but meaningfully reduces that cost. In a sentence, plugins increase the area-of-compatibility-concern quadratically.

Goal of Using Neovim

I’m comfortable, in theory at least, to customize nvim. That, plus its wealth of code motions and operations (for which I’ve been a middling amateur!) feels like it opens a lot of doors to improving the inner loop of my work. “Surround” motions, registers, marks, and of course the genuinely-great plugins available are things that, if I really internalize, might very well really help me. So I’m going to be looking at neovim with that aim.

Work Style

Using Tmux the Way I Want

So I’ve begun typing up notes on how I’m revisiting how I do software development (hobby, professional). I’ve heard furtive whispers of this tool, tmux, and how amazing it is. Youtube, oddly, seems to be a valuable resource for learning about this stuff, so I found a few popular-seeming videos: this one seems particularly popular, but I found a few other handy ones. This blog was probably most valuable for me (if you can’t tell, I prefer blogs over videos, which seems contrary to where things are going…). Again, to be clear, I did cursory searches and these are what came up—maybe there’s better resources!

My Hopes for Tmux

Long ago (in college) I had a lot of fun with Emacs and so I recall how I could split windows, have one window be a terminal, another be my editor pane, and still another run top, and so on. (I still readily split views in my VSCode instances). I have a large monitor, and so the pane-splitting (plus the different windows) suggests a lot of nice tiling abilities. So I’m leaning into that.

More concretely, I often have an editor (Neovim, now) in one pane, maybe split in 2, and then an incidental terminal to do git-y stuff, and another terminal to do test-runs, and then maybe another tiny one running top (or the cooler htop) to let me know if something awful is happening to my machine.

Tmux has additional tools, particularly it’s ability to “detach” from sessions. My impression is that it’s for system administrators and the like; it’s not something that I see as useful for what I do.

Bringing it Up

OK so I’ve done a few things:

  • choco install nerd-fonts-hack to get that sort of psuedo-graphics font that’s all the rage.
  • In Windows terminal, change my WSL instance to use that font. Additionally create a colorscheme to match the one I’ve decided to commit to (for a while…), “tokyonight”, using ChatGPT :|.
  • Install tmux.
  • Ask ChatGPT how to set tmux on connecting to WSL. It worked! Just a little function testing the TMUX environment variable.
  • Create in my shell profile a function (etx, in my case) that jumps to the config/tmux/tmux.conf file and, upon saving-and-exiting, reloads the file. So I can futz with it easily.
  • Again ask ChatGPT to make Tmux tokyo-night-ish via the conf file. (This was not completely error-free: I had to do a few iterations, and futz with a few things, to get it working.)
  • Additionally augment that conf file with some better hotkeys and minor things.

That’s it!

Notably: No Plugins

Plugins can be very handy; you’ll see that I’ll use them enough in Neovim. Tmux (and also Fish) have their own plugin ecosystem. Of course it’s wonderful there are so many people sharing their efforts to improve their environment, but I’ve found that the cost of getting differently-authored plugins to be mutually compatible—even despite everyone’s best efforts—is too high. Of course they typically work well together, and of course avoiding plugins doesn’t preclude bugs, but they so rapidly increase the surface area of what to investigate when “something goes wrong” I try to avoid them.

Thus you’ll see that in my tmux config and fish rc file I avoid plugins (so far…?), while in Neovim I concede their use but still try to reduce my dependence on them.

Work Style

Revisiting My Tools

Part 1: Context and Goals

Every few years I end up feeling motivated to change the tools, or how I use the tools, to do my hobby programming and writing (and professional work). This time has come again. Oh no.

The conceit is, of course, that new usages and tools will be “better”, and I will consequently be more effective at what I want to do. In truth it’s hard to really see that happening on net. So this is basically for fun, but I can hope it will lead me to a durably-better place.

Anyways, this time I’ve decided to really lean into the idea of improving my inner-work-loop: really be conscious of what I’m doing when developing or writing, and so see opportunities where I’m doing something silly. Things like ensuring I’m doing incremental builds, handy Vim motions, running very targeted tests, and so on, are easy to put off, and I think I’ve put them off too much. I say this partly as a reaction to the other direction, where people spend their whole lives optimizing their Vim macros (or whatever) to the detriment of the work-actual these tools are purported to help!

So I’ve decided to take the time to do a wholesale revisiting on my off hours. (This has the added advantage of being mentally simple: I’ve not had the mental energy to really dive into caching algorithms the way I had hoped, as I’m currently stretched thin in a few ways.) The tools I’ve assessed and decided to lean into are:

The actual OS will be WSL on Windows, and I’ll be using the Windows terminal as the entry point into Tmux.

Next Steps

I’ve actually already done quite a bit in learning and getting used to the above tools already. I anticipate a sequence of blog posts following this in which I either opine on tools in general, or include notes on what I’m doing in particular. Writing this out might help me durably remember some useful tricks, and at least force to me articulate what I’m trying to get out of this latest round of revisiting. For any other readers, hopefully this will be interesting or useful.