A Love Letter to Neovim
46 points by Caio
46 points by Caio
i vividly remember, some 20 years ago, taking stock of what made my day-to-day work pleasant, as opposed to simply productive. top of the list were linux and vim - no matter what the job was, and what tech stack it involved, those two things made sure i had a comfortable (in both the "ergonomic" and the "cosy and familiar" senses) environment to do them in.
Began using vim perhaps 12, 14 years ago ... mostly because I wanted a lean editor that'd get the code in front of me. I unplugged the mouse and began learning (I was quite happy to learn Mitchell Hashimoto had a similar learn-vim experience)
I can't recall exactly when neovim showed up on my radar, but I know how it did. TJ DeVries (https://www.youtube.com/@teej_dv) and his YouTube channel. He was hacking on neovim, telescope, and a bunch of other projects. The move to Lua felt right, and I loved that little language already. My vim config had begun to feel stale and non-malleable.
I recall my first plugins were treesitter and telescope, and I ran neovim with those plus a few other small ones (statusbar) for awhile, and still do. neovim never breaks for me, just works. No LLM plugins (that whole ecosystem can sit outside the editor).
I'm hopeful the team continues to deliver a lean and focused code editor, and nothing more.
Similar story. I used vim and emacs for years, preferred vim, but was always jealous of the fact that elisp is a pretty nice programming language whereas vimscript was... um, yeah. So neovim adding Lua made it very attractive.
neovim is bizzarely consistently the editor with best LSP support. sure, VS Code gets more language-specific features (although plugins like rustaceanvim help to close this gap), but lsp lines (now built-in) diagnostic display is a game-changer for me, and most editors don’t even have semantic tokens.
ooo lsp_lines looks nice, I've been using https://github.com/rachartier/tiny-inline-diagnostic.nvim which is similar but requires hovering over a line to see + opened diagnostics cover text instead of creating virtual lines.
By built-in, you mean vim.diagnostic.config({ virtual_lines = true }) is in the base now and does the same thing? It certainly seems available (even in 0.11!), guess I'll try it out
yeah, I think it’s the same code just merged upstream. I recommend having a keybind to toggle it and auto-disabling it in insert mode, as it can be rather noisy when you’re typing new code.
I love the vim model. The modal editing is only a small part of it: what I appreciate in vim more than in helix or any normal IDE is that the learning is incremental: first you start with understanding the keybinds and the setting of the options, then you get conditionals in config because something doesn't work on windows, then you write your autocmds, functions, then you extend it to a small plugin using the things you've learned before.
Saying that, I don't love neither vim nor neovim. One of them because it's had the same weird bugs for tens of years now left unfixed; the other has fixed a lot of the bugs, and introduced some more. The biggest sin of neovim is breaking the lua api on each update. I'm tired of launching it, seeing a deprecation notification, and having to rewrite my config every time instead of doing what I was going to do. This wouldn't be so bad if some new functionality wasn't lua exclusive, otherwise you could just stick to vimscript and be happy with the compatability going back more than 20 years.
I first started to learn vim, beyond :wq, when I was interviewing in 2009 because it was the only way I could pair with the employees that all used vim. (I won't name names but some even unbound the arrow keys.) Prior to that I only had terminal editor experience with pico during college, since I was using whatever the current GUI editor trend was at the time. I was lucky enough to be hired which started my continuous usage of vim since.
Recently I realized that it kind of crept into other parts of my software life. I think it started years ago by using Hammerspoon in macOS to create virtual keyboards for a window management submap. And when I started trying out Arch Linux late last year it made tiling window management so easy.
I converted to neovim a while ago and it really is great. And while I know there are tons of jokes and wars about editors, beyond a few edge cases I still really find it hard to understand how people who write code for a living don't use vim, emacs, or similar editors. Picking the best tool for the job applies to any profession and "[treating] editing like a language" is a huge advantage in software.
The post is cool, it is why I love Neovim, not why you should.
About "hard to understand" in the comment above: A decent amount of actions, shortcuts, and plugins like the ones in VS Code are extremely useful. People should read the large VS Code documentation. It does a lot.
And for some, me included, clicking to move the cursor to arbitrary places in the buffer and selecting arbitrary chunks with a mouse is simple and plenty fast. KISS.
You can use the mouse in neovim - and og vim too - just fine. I think it's even enabled by default on many distros these days.
:set mouse=nvi
:help mouse
# or to disable
:set mouse=
put in ~/.config/nvim/init.vim for permanent.
Maybe that's what you do already (it's not clear from your comment if you're already doing that in nvim or still hanging on to vscode?) but sometimes I do see people voice the incorrect opinion that you can't easily scroll with mouse or trackpad in (neo)vim.
This reply is not intended to yuck your yum
My experience after using vim is that going back to the mouse feels very unreliable and I have to try a few times to get the exact characters I want
Maybe my aim has just gotten worse due to a lack of practice
Yep, I have used Vim/Neovim regularly in different time periods. The lisp syntax file still credits some contributions of mine from the late 90s. Also a heavy Emacs user for some years, and have used most editors out there.
That experience you describe is common, many people seek Vim motions in all apps. But not universal!
In my case, for the last years, VS Code is a deliberate choice among what is available. It has a balance of power and simplicity that clicks to me.
I still really find it hard to understand how people who write code for a living don't use vim, emacs, or similar editors.
I use vi modes and motions almost everywhere, but I only occasionally use vi, vim, neovim or emacs (with viper). That's because I find that other editors are often the best tool for the job. For me, when I'm writing python, which is what I do most often lately, I find that PyCharm is a better tool than any of those. Thankfully, it's got a very good plugin called IDEAVim which lets me keep my muscle memory. As a bonus, since I use it on a mac, none of the system keybindings overlap the vi ones, so I can use whichever makes the most sense. When I'm writing C++, I find that Clion is a better tool for that job. But IDEAVim works there too.
I use zed frequently for random chores that don't fit into one of those categories. Its vim emulation is quite good.
While I certainly like to have a nice terminal editor when I'm remotely accessing a system, TBH I don't really love using a terminal editor when I have a full GUI available to me, even though I do love a modal editor. I think there are good reasons to use GUI editors, especially when I don't have to abandon my muscle memory.
VS Code won because it is good enough for almost everyone and easy to extend.
VS Code is "good enough" for a lot of use cases out of the box. It already has ctrl-p 'search for files', split panes, highlighting, and popular language support. I was hoping neovim would at least ctrl-p out of the box and maybe some more, sort of analogous to Linux Mint, except for vim-style editors to avoid the security concerns and setup hurdle.
When I am SSH’d into a machine, pairing in a tmux session, or fixing something from a tiny terminal window, I want the same editor brain I use every day.
I've been paid to write a lot of code in screen/vim over ssh. It was actually incredibly productive since it was before "slack can ping at any time" sort of constant interruptions.
The debugger has its own little world
Visual debuggers like in Visual Studio, Jetbrains IDEs (CLion, Rider), are the one thing I never had a good equivalent for in any vim editor. There's a lot of power there more accessible than with something like cgdb.
Speed is not just about startup time, although Neovim is great there too
Stock Neovim shutdown though is noticeably slower than vim. Not super long, but ~1s for me.
vscode with the neovim plugin is the sweetspot for me. some jank where they conflict but it's easy enough to work around usually. a real vim instead of an emulated vim is really nice to have in an editor with all the nice things vscode brings.
Stock Neovim shutdown though is noticeably slower than vim. Not super long, but ~1s for me.
That feels abnormal. What is "stock" in this case?
% time nvim -u NORC -c ':q' <random or no file>
nvim -u NORC -c ':q' 0.02s user 0.01s system 71% cpu 0.042 total
# Even my normal config loads and exits faster than that
% time nvim -c ':q' <random file>
nvim -c ':q' <random file> 0.23s user 0.16s system 84% cpu 0.458 total
I've been using vim since I started using Linux in the 90s and yet for my daily work stuff in an IDE, I prefer something like IntelliJ with vim bindings.
vim (or recently) neovim is installed and configured on every machine I own (or have access to) and I might even use it several times per day - but except for small hobby projects I kinda still prefer some full-blown IDE, and I'm not mad. Guess I'm doing a lot more stuff than typing and moving lines around.