Monthly Archives: October 2024

Interview Questions

Neovim Rant 1

Getting Python Autocomplete

I use python to help collect some high-level commands, such as in my SAT solver. I’ve said previously that I don’t want to use nvim as an IDE, but I do want lots of nice features. (So by “not an IDE” I mean not really do much for file-exploring, git(hub) integration, etc: the tools are only to help edit text, leaving other more focused tools to do their thing.)

There’s syntax highlighting, linting, autoformatting, and autocomplete stuff. To my mind these are just examples of supporting a language, but apparently in nvim they’re all sort of different components. I followed along this nice video to get started (in a lot of ways; the language support is later, and to be clear I recommend this video a lot) but the pieces involved get a bit silly. As I get more plugged into the nvim world maybe this will feel better, but until then…

  1. I had to choose a plugin manager. Apparently lazy is the new hotness, though the purported lazy-loading seems never to be used?
  2. NVim supports the LSP, which is the root of all this functionality, but apparently there’s also a separate plugin you need to “really” use it?
  3. My impression is that NVim is an LSP client, but you still need per-language servers, which are separate executables (!, but fine…) for which you need another layer of package-manager-recursion: Mason.
  4. For auto-formatting (which is nice) one recommends this server, which is integrated with this plugin.
  5. Using pyright apparently required some treesitter stuff (a dimension to all this I haven’t really explored!), which ultimately meant I had to download and install npm, and futz with my path, and then I think everything sort of worked.
  6. Well I needed to do something with nvm-cmp too.

I think there were a few more steps, but I hope this speaks to the number of discrete components I had to futz with. I see the appeal of pre-made distributions like LazyVim.

Can This Be Easier?

I have some familiarity with implementing language tooling. I’m reasonably confident with what’s happening here: people have managed to factor the “incremental-compilation” aspect of IDEs into this LSP language, and that allows for modularity: any language developer can implement an LSP server and it can provide some amount of information to clients. The functionality to consume that information is itself separate: so far it seems like theres’: [LanguageServer]->[Client(Neovim)]->[Tool(AutoComplete plugin)] or something. I suppose this allows users to, e.g., define their own hotkeys for the single autocomplete tool, and have that intelligently consume the LSP information for any language, which is neat.

I believe that the components here have a reasoning behind them, but I think their presentation would be better served by having a few minutes saying why this is the way it is (versus, say, a Python plugin that has all the options you want, a C++ plugin that has all the options you want, etc…). Having to go to 3 different plugins or whatever, and manually install third-party tools (even if there’s a plugin that does that installation for you!) is, to my mind, not ideal.

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.