Neorants Issue 1
Thoughts and news from your (not always friendly) neighborhood maintainer.
This is the first of what I’m sure will be an ongoing series of sporadically delivered and ill-conceived posts on the happenings in neovim development, and the neovim ecosystem (Think, this week in KDE/matrix but snarkier). If you want me to write about anything in particular, or showcase your plugin, please file an issue at the repo. This is probably going to be biased towards LSP stuff for the time being, as that’s where the majority of my contributions have been.
Borders have been added as an option for floating window (by bfredl), and the language server client helper functions have been updated to take advantage of them (by elianiva and I). You can set the color and style of your border however you like (including the color per corner if you want to get crazy).
I also made the hover handler return the buf id, so you can also set custom callbacks (like having the hover triger also return you back to the original window). See below and
:help nvim_open_win()for more options on customizing the border.
Async/await utilities to leverage lua coroutines (cooperating multitasking) were added to Plenary in PR #83, and PR #709 was merged in Telescope to use async/await for all but live_grep (Yay non-blocking input). These abstractions, like most of plenary, will probably someday be integrated in core.
There’s a bug in luajit that seems to effect protected calls to neovim’s json_decode (see Issue #14246). The safest option, as always, is to clone the neovim git repo and compile directly from source. This assumes you have installed the pre-reqs.
Unlike AUR, we vendor the luajit version so this build process will not be affected by upstream luajit changes.
I was unleashed to start the neovim discourse, and it’s been a surprising success. For those not in the know, it’s a FOSS forum application, with hosing for open source project generally provided by the parent company (Rust, Julia, and NixOS are agmongst other users). Traffic numbers are really good, and continuing to grow. I’m generally pleased with how proactive people are in answering questions!
The neovim website got a redesign, with new links to showcase configurations and the discourse (discourse.neovim.io now redirects too)
I saw a proliferation of 50+ file hydra-like neovim “starter” configs, so I made one that I consider a fairly good starting template (see below).
A number of new plugins have come out recently. I’d recommend checking out the following
I’ve been really busy for the past month or so with school, so I’ve spent most of my neovim-time reviewing PRs. I did work on a couple things.
The first, is a template configuration pretentiously named defaults.nvim. The idea here is to create a configuration that gives you 90+% of the functionality one expects with a modern text editor, but without becoming an unreadable mess (small, documented, single-file). The goal here isn’t to be SpaceVim/Doom, but rather to give people a strong, documented starting point.
I did some cool things with this, like including a nix flake. Nix is a pure, functional package manager that works on MacOS and Linux, and provides a level of deterministic evaluation beyond containerization (docker). This prevents the “Neovim nightly doesn’t work because I installed from AUR and they bundle a bad version of luajit” and the “I installed Neovim + lsp but python completion doesn’t work (because I never installed a language server) type questions”.
Second, I wrote a terrible plugin called Babelfish. Most of it was done between the hours of 1AM and 3AM on a Friday night after a conference deadline. I plan on working on it intermittently, but TLDR I want to never have to write vim documentation again (It’s a Markdown to Vim Documentation converter using tree-sitter).
Stop filing issues that say “X doesn’t work”. I don’t know why this happens so often with the language server client in Neovim core, but 90+% of these cases end up being a configuration issue (what are y’all doing in your configs!?). You need to reproduce starting with a minimal neovim config, no core member is going to wade through a 5000 line custom config filled with plugins. I’ll be writing a basic “how to apply binary search to configurations to write a good github issue” guide soon-ish.
Stop filing pull requests to change CONFIG.md in lspconfig, it’s autogenerated, you need to change the source file from which is derived.
There is basically 0 reason to rewrite your init.vim as an init.lua. I feel partly responsible for starting this crusade, but it’s spiralled. There’s no speedup unless you’re writing tons of custom, expensive functions in your vim config. The only reason I do it is because I write a lot of lsp extensions/handler overrides in my config when debugging, and I like having a good language server to check them for correctness.
Reddit has a weird blood-feud with vimscript for some reason. I see so many “Looking for an alternative to X in lua” type posts. Unless plugin authors start adding vimscript 9 without adding checks for old vim versions (and neovim of course), there’s no reason to migrate to a lua plugin for the sake of it. It’s not guaranteed to be faster, and you can use vimscript plugins from init.lua.
Every single time the nightly goes down (Github actions are great y’all), about 10 people show up on IRC asking if we’ve discontinued the nightly. Every. Single. Time.
See above but s/nightly/website.
Things to look forward to
- PR #12593 I’m really excited about having a built-in mechanism for file-change detection in neovim. There are a lot of cool things, particular in regards to sending file-change detection events to language servers.
- PR #14122 Semantic highlighting (think Semshi) is something a lot of people seem to care about. Semantic tokens are part of the LSP spec, but currently not implemented in core. This PR by Smolck changes that, and is the building block from a semantic highlighting plugin. But treesitter you say!?!? Yes, there’s some duplication of functionality
- PR #14462 I’m always suprised at the number of people using multiple language servers (although, let’s be real, 99% of this usecase is tsserver + efm). This PR will probably result in some changes to how buffer formatting works with LSP.
- PR #13479 TJ is making all of your vim.g/o/w/wo woes go away… eventually. Although are y’all really changing your configs around that much!? Set it and forget it.
- PR #12378 TJ strikes again, this time with autocommands. I’m actually really excited about this one, mostly for future possibilities. I would love hierarchical namespaces for autcommands (imagine clearing all LSP autocommands on a single buffer).
- PR #9496 Bfredl is working on making virtual text even more powerful. This is a PR long in the making, but it’s very cool!
Ideas for next issue
- What are extmarks?
- What is LUV? (Baby don’t hurt me, no more)
- Talk about goals of neovim-ui, neovim plugin specification, other half-baked ideas I’ve had and not followed up on