Anyone unfortunate enough to listen to me talk about tech for more than a few moments will likely find out that I’m a big fan of Neovim. It may not always be the editor that I use, but it’s by far my favorite. While some people don’t like the idea of having to “fiddle” with their editor to get it set up the way they want, the fact of the matter is that most anyone who wants their editor to be just the way they want it is going to have to fiddle with it; the big difference is whether or not the editor gives you the extensibility. I personally love the idea that I can keep my editor’s configuration, plugin list, keybinds, etc. all in a single file. If I need to install it on a new machine, I simply clone the file and I’m already done.
Neovim users just may have to do some extra fiddling if desired functionality isn’t available out of the box, and that’s the situation I recently found myself in. When using something like VS Code (or even the GitHub web UI for viewing code), it will pin the current code context to the top of the screen so that you can always see what class, method, etc. you’re currently operating in even if those actual lines of code are far off the top of the screen. A screenshot will easily showcase it better than I can describe it:
This screenshot is from VS Code. The top line of code is line 120 and show that I’m in the DashboardList class. The next line is number 179 and shows that I’m in the post method of that class. The third line is 183, and this is the first line of code that should “normally” be visible at the top of my editor. In this way, I know which method I’m in and for which class that method belongs regardless of how far removed that context may be from my current line of code.
While it may be easy to think that you’d always remember that sort of thing while working on code, when quickly jumping around within a file or across multiple files it can be annoying to have to scroll up to make sure you’re operating in the right place and then back down to the relevant section, no matter how quickly things like Ctrl + u and Ctrl + d make that in Vim; I really wanted the same context in Vim as other editors. As is always the case, there was a plugin to the rescue.
In this case, it’s made by the same organization behind the amazing Treesitter Neovim plugin that I’ve been using for years. It’s simply called nvim-treesitter-context, named because it’s an alternative to the context plugin. I actually found both plugins at the same time and opted for nvim-treesitter-context because it seems to be updated more regularly and is created in Lua rather than Vim Script.
While there are configuration options for it that are covered in the README, I’ve currently been pleased with how it operates out of the box. Here’s the same screenshot as earlier but in Neovim:
It works like a charm, and I’m quite pleased to be able to make my Neovim configuration just that much better.
3 responses
[…] I’ve talked about plenty of times before, I tend to use a lot of different text editors when writing code. Lately, I’ve been using VS Code for most of my […]
[…] and develop that way. This does require proficiency with a CLI editor, but as someone who loves Neovim that’s not a problem for me. The bigger problem is that leaving something like Prompt in the […]
[…] the uninitiated, every time you open a file in Vim (or a derivative, like Neovim in this case), it will create another file on the file system that has the same name as the […]