Vim After 15 Years (2017)
blog.langworth.com
blog.langworth.com
I've been meaning to write a follow-up article, but unfortunately writing is low on the priority list. The main reason is that these days, when I _am_ coding, I mostly write TypeScript and React on my local machine (not much SSH these days), and VS Code Just Works™. I tried twice to get neovim and LSP stuff working but never could, and I can't justify spending time twiddling my editor these days. And as much as I love the terminal, using multiple font sizes lets me fit more information on the screen.
My dotfiles are always available: https://statico.link/dotfiles
(Also, I lost all the great comments on my blog somehow, so sorry to those who left them. I had Commento running for a while but it appears to be abandoned. Disqus has them but I refuse to use Disqus anymore because it's awful.)
Some notable examples of things I would have used the command line for a decade ago:
- Gmail for email (I'll switch to Fastmail someday)
- The eight billion other chat apps I use — I dropped IRC many years ago but used IRCCloud to ask NetHack questions recently
- CyberChef for exploring binary data
- Pixlr for image tweaking
- Google Sheets, Airtable, and Notion for notes & databases
- A password manager for passwords
- Pinboard for bookmarks
- NextDNS & PiHole for DNS settings
- Postico for Postgres (not web-based, but massively I'm tremendously more productive with it than with psql)
Running Neovim in something like WezTerm, Kitty or Alacrity is closer to what it was like to use a GUI version of Vim (like MacVim) not too long ago.
Full-color support, full OpenType support (like ligatures), built-in multiplexing at least in WezTerm, in a fast, GPU-accelerated UI.
Neovim's support for the same LSPs as VS Code + support for Treesitter.
+1 for LSP-Zero, which makes configuring LSPs and linters trivially easy for Neovim.
I'm not suggesting that you or anyone else should use Neovim instead of VS Code, but I've certainly read enough blog posts about TypeScript and Rust developers moving from VS Code or IntelliJ to Neovimn for a variety of reasons. I've seen Neovim core developers coding on YouTube and Twitch and they look pretty productive to me.
I've attempted to use VS Code; it usually starts okay but doesn't end well and I go back to Neovim.
Neovim hasn't made it to version 1.0 but so far, it's on the right track and I love the vibe of the Neovim community.
for f in **/*.go~vendor/*; gofmt -w $f
for f in **/*.go~vendor/*; gofmt -w -r 'a == false -> !a' $f
for f in *.qcow2; printf '%-30s %-15s %s\n' \
$f \
"$(qemu-img info $f | grep -o '^virtual size: [0-9.]* [KMG]iB' | sed 's/virtual //')" \
"$(qemu-img info $f | grep -o '^disk size: [0-9.]* [KMG]iB' | sed 's/disk size/used/')"
It's really flexible and just as "simple" or simpler once you know all the tricks. Learning all the tricks of course takes a long time; say hello to my teenage years with no friends or girlfriend.
Anyway, aside from file management and Vim I do almost everything in the browser, and more or less always have, but for some things it's hard to beat a good shell.
To be honest, that was true 25 years ago for most of us. Some programmers could have perhaps gotten away with only the terminal, but most people using computers in their work have long had to use word processors, spreadsheets, and other critical GUI software if we wanted to keep our jobs.
I used mutt for email, irssi and the bitlbee proxy for chat, wrote styled docs with LaTeX, etc. When I interned at IBM in 2005 I was even able to get Lotus123 or whatever horrible email thing they used to work with mutt, and my supervisor even encouraged me because he wanted to use it, too.
What I miss however from the good-old development in Terminal days:
1. How distraction-free terminal is by default without all the popups and extra things on the screen
2. How I could do anything in my development environment without having a mouse
Therefore naturally I checked your dotfiles and I think I will try to adopt your keybindings. Thanks for sharing.
The neovim lsp story with lspzero is as pain free as I can imagine things to be, so that also helps. In this day and age for the languages I use, neovim is a lovely and blazing fast IDE.
Finally, for the way I like to work, the terminal is often the IDE. One thing I couldn't ever get used to was terminal inside the editor rather terminal being the primary thing. It's why my many attempts at Emacs failed too.
Emacs can run in a terminal too, that's how I have been using it forever inside tmux.
I said then that if someone would make a text editor and IDE that used JavaScript from the ground up instead of elisp, that it would dominate, and that's what seems to have happened with VS Code.
I know what its like to be burnt but messing with config, but man I cannot recommend kitty + neovim highly enough. It's absolutely AMAZING.
"Deliver a first-class Lua/LuaJIT scripting alternative to Vimscript." The rest seem fine but not really a reason to switch, and I don't know Lua so I'm not sure that's a reason either.
Is this the main reason? Are there other good reasons?
Probably I have the wrong mindset, but I've always tried to replicate a full IDE experience on nvim, and it was a frustrating experience because there was always something else missing, at the end I had to manage 30+ Plugins that could break at any time.
Even though the vim experience inside VSCode is far from perfect (really lacking when we compare with IdeaVim for example), it's a breath of fresh air being able to manage my plugins/lsp/etc with a single click.
The only thing that I miss daily is something like Telescope/fzf. VSCode fuzzy search works fine for file names inside the open project, but searching for file content/other projects/previous open files is really bad.
Recently tried to develop something similar on vscode just for fun (Even I don't use it tho, just accepted the limitation): https://github.com/jpcrs/Binocular
I think it's more reasonable to use VSCode rather than trying to turn Vim into a monster it wasn't supposed to be. I see Vim a simple modal editor, which can be integrated in other tools such as IDEs.
in any case, thanks for your comment
As I get older (33 now), I feel more and more annoyed by Things That Just Work TM changing on me for (IMO) no good reason. There are very few applications that I update as soon as I'm notified, because more often than not, something changes which at best disrupts my workflow and at worst breaks it. It seems as developers we are both best placed and very much expected to cope with this onslaught of change in our tooling. But when something that worked 2 days ago stops working, to me, that's only an impediment and I feel zero excitement for whatever improvement might have justified it. IMHO.
To me, Vim is a stable, battle-tested, and (IMHO) quite ergonomic way to write and modify code. At this point, I know what I'm doing when I write code (mostly.. maybe), how I want to do it, and I only want to do those things the way I want to do them. To me, Vim is my workshop, a workbench with my tools laid out on it exactly where I want them. Something like VS/VSCode feels like a public space with toolboxes everywhere, which I have to step around to work. I have no idea what's in some of these toolboxes, nor do I care, and I'm pretty sure I saw a lawn mower in here somewhere.
Obviously some people out there, people with a brain wired differently to mine, can work productively or even enjoy that kind of environment, but that's not me. At the risk of sounding like a wanker, I just like the zen of working on some code without all of the noise, in the same way I've always done it. It feels good to be efficient. Hell, there are enough self-inflicted frustrating moments in software development without my tools turning on me, too.
So I use Vim because I'm happy to sacrifice the incredible, broad capabilities of something more for a tool that gets out and stays out of my way, and that I know has no agenda beyond doing exactly what it says on the tin (and maybe soliciting some donations for Ugandan children).
I've tried several times Vim and I just don't get it how you can live without certain functionalities, I'm sure that with enough tinkering you can get pretty close but, for example, search seems to always be kind of a pain in the ass for the complex queries with regex through many files and stuff like that, specially the presenting of results has never been close in my opinion as to something like IntelliJ does it.
Things like "god damn, I've done goofed or I don't quite remember something" and having the internal file history with a diff readily available.
Some of the click and find implementation/usages never seems to quite there to me.
I could go on, if you're truly being productive and not missing out on feature, more power to you, but I honestly wonder if there's no element of fun/pride in using something like vim now-a-days, which of course is totally fine and way more important in my book (to an extent) to pure productivity.
There is also the point of being able to use vim bindings inside of the IDE.
Maybe I'm just an idiot that can't Vim, totally open to that idea, but I'm truly wondering how productive it actually is.
> I don't quite remember something and having the internal file history with a diff readily available.
You're already in a terminal, git is just one command away
> Some of the click and find implementation/usages never seems to quite there to me.
This really depends on the language you are working in, but generally vim's gd (and plugins that augment it) enough most of the time, otherwise grep/rg if you know what you are looking for. If you are using something really dynamic, e.g. ruby, then you're pretty much shit out of luck.
> I could go on, if you're truly being productive and not missing out on feature, more power to you.
Here's the thing, the best part about it vim is that it is not slow (plus paired with a terminal emulator like kitty/wez/alacritty). When I type the characters actually appear on the screen as I type them. With most IDE's (at least the ones I have used) there is a noticeable delay from when I have stopped typing and characters appearing on screen.
Another thing to add is that vim is very fast to start up and shut down, I open and close vim multiple times as I am working. With an IDE, startup times are atrocious and dont really fit my work style of cd'ing somewhere quickly editing something, cd'ing somewhere else and rinse and repeat.
In general I find the original command line tools to be much better than IDE provided equivalents or integrations, there's no unnecessary animations and much less cpu/ram usage. Though one exception for me is the database clients, where I much rather prefer a GUI than using the CLI client.
Your tests are already runnable from command line (assuming CI is setup).
Basically, Unix becomes your IDE
I just noticed that ~/.vimrc adds a small delay, even if it is empty. This is the test case:
Create a file with about 10 emtpy lines and type:
esc switch to normal mode
gg go to the top
ctrl + v, G select all lines
shift + i switch to insert mode
- line just type something
esc this will duplicate the first line until the end of the file
Great quote. Perhaps one of the best arguments for using Vim
Regarding your specific examples, both vim and emacs have file histories and if your files are under version control it's easy to get diffs.
Searches are super powerful in both vim and emacs, and it's easy to search across multiple files as well using various scripts/plugins.
The main downside to using editors like vim and emacs is that you have to be a pretty advanced user of them and spend a lot of time configuring them to really feel their power. If you've just dipped your toes in they're not going to look very impressive and you'll likely be disappointed.. but invest the time and they're very hard if not impossible to beat.
Having a good debugger integrated with my code editor is basically the reason I use an IDE instead of vim. Stuff like Vimspector exist but are way more work to use vs. a GUI equivalent.
I have a (maybe overbroad) critique of GUI software which is that it mostly brought us pixel-level graphics at the cost of extremely restrictive UX. Or said a different way, GUI apps look better but they're usually harder to get work done in.
Part of that is toolkits, part of that is you're using a mouse which is like driving a space ship with a single finger, part of it is the expanding user base of computing (to people who don't necessarily want to learn say, regular expressions). But like, I script GDB. If your IDE debugger won't easily let me do that (or it will but it's a painfully convoluted UX), it doesn't really matter to me that it (subjectively) looks nicer.
The sole exception in my opinion is remote debugging (it’s not too bad, but JetBrains really bootstraps this part very well).
One notable exception is that neovim has treesitter, so you get immediate semantic analysis on your code which allows for much more flexible refactoring. Like everything in vim, you need to spend time setting these things up to streamline your common workflows.
I've rarely had a problem with search, I can type `:grep [some regex]` and I'm quickly shown all matches for that regex in the entire project. I admit I'm not sure how I would do a more complicated query, but this is almost always enough, what kinds of queries do you do which this doesn't cover? There's just one exception, I'm currently working in a codebase where members have very generic names, `Nonce` is a valid field name for a number of different structs, which makes search results for `Nonce` tedious to work through. For this situation I've added a keybinding which calls semgrep and lets me view all references for a specific struct's `Nonce` field.
Calling out to semgrep is an instance of a more general pattern: Because vim is not integrated I lean on tools outside of vim when necessary. The `git` cli, especially once you add some aliases, gives fine access to file history and diffs.
The feature I'm most jealous of is debugger integration. `gdb` and `dlv` get the job done but it's really convenient to be able step through your code with the same interface you use to write it.
> There is also the point of being able to use vim bindings inside of the IDE
Every vim keybinding re implementation I've tried has been missing essential features. When I'm inside an IDE I spend much of my time typing and navigating. When I'm inside vim I'm _thinking_, and the necessary changes occur about as quickly as I decide upon them.
GNU id-utils provides a mkid command which scans a directory of files to build a binary index file called ID. The lid tool is used to query this and provides a grep-compatible mode.
lid sometimes puts out things in a funny order, so I sort the output.
:set grepprg=lid\ --word\ --result=grep\ '$*'\ \\\|\ sort\ -n\ -t\ :\ -k\ 2
Or, if you'd like :grep to use git grep:
:set grepprg=git\ grep\ -n\ '$*'In a large-ish project like the Linux kernel tree, there is no perceptible delay.
I use ctags in parallel with mkid; different tools for different job.
Speaking of :grep, I have it mapped to the K key.
The default action of K is to do a man page lookup of the word under the cursor. I changed it to grep instead. ... and I preserved the man page functionality too. The default K takes an optional prefix (man page section). I have it so that if I give a numeric prefix to K, it will do the man page lookup for that section:
:nmap K "_y:execute count ? ( ":!man " . count . " " . expand("<cword>") ) : ( ":grep \\<" . expand("<cword>") . "\\>")<CR>
:vmap K "zy:execute ":grep " . getreg("z")<CR>IDEA out of the box has:
- fuzzy text search across your entire codebase. Supports regexes, when you need them
- fuzzy text search for symbols only (e.g. when you only need to search for method names etc.). Supports regexes, when you need them
- fuzzy text search for file names
- Ctrl/Cmd + click, or Ctrl/Cmd + B on any symbol, and you'll get a list of all the places where this symbol is used (e.g. a method name that's called from various places in code, including test code)
No extra plugins, or setting up keybindings, needed.
With vim though... Even discussion on search devolves into listing which tools everyone uses, with which options, and a discussion on how circumvent their limitations.
Edit: esp. with search almost every year there's a new tool that you absolutely must use because it's better than the previous tool. ripgrep, ag, telescope, treesitter, semgrep, use them all!
> Edit: esp. with search almost every year there's a new tool that you absolutely must use because it's better than the previous tool. ripgrep, ag, telescope, treesitter, semgrep, use them all!
Aren't you also doing this? "Use IDEA, it's great for searching!".
I think there's something to be said for aesthetics here, where if you like typing you're gonna be into the grep/ripgrep/find aesthetic, and if you like GUIs you're gonna be into IDEs. People trying to assert some kind of objective superiority of their tools over others' is kind of tedious. Use what you want.
Editor + shell + tools is the IDE. And I like that I can swap out tools as necessary.
I'm simply faster in it. I'd probably say the initial main attractor was modal editing (vim-mode plugins in Jetbrains are not my favorite - usually not a full implementation of the real features vim offers).
* For syntax highlighting: tree-sitter is as good, if not better in my experience.
* For auto-complete/navigation/etc: LSP support + a small few plugins solve this, running on par with what GoLand offers.
* Search support, like the case you mentioned - I use Telescope + Ripgrep and usually my searches are roughly the same time to process as GoLand did.
Are there other features that are drastically important? Because the other features Neovim offers over GoLand are:
* It's way faster to load. Indexing in GoLand takes so long. LSP servers do usually take a bit of time to index but this is on the order of minutes faster than GoLand takes for the projects I have to use at work.
* Significantly less memory consumption.
* I can be purely keyboard driven.
* Modal editing and all the niceties that come with that (note: emulators are always subpar in my experience).
* Being already in the terminal is a significant advantage, especially on my laptop screen (less-so on my ultrawide).
* Customizability is a lower priority, but it is still worth mentioning - there's only so much you can do to customize a Jetbrains editor.
I am far more productive using it than I ever was with GoLand. I might make the exception for IntelliJ when I used to do Kotlin work - but that's the exception, not the rule. For every other language I definitely prefer Neovim.
I think, like all tools, it's important to spend the time to learn it (if you desire to actually use it). Otherwise, of course vim will just look like some archaic tool that seems like it lacks all modern support.
# queries/python/injections.scm
; inherits: python
((call
function: (identifier) @_func
arguments: (argument_list (string) @sql))
(#eq? @_func "text"))
neovim plus a couple extensions plus some Unix command line tools are just so simple and convenient.
vim's "design decision" to have extensions and external tools that you need to manually string together somehow is just as infuriating.
I use an IntelliJ plugin that notifies me when I could’ve used a shortcut but I clicked with the mouse instead. It also counts the times I missed a shortcut. I keep a pretty low count but I was watching a colleague that had the same plugin and he had missed a certain shortcut 22k times. He is as productive as I am, so to each his own
Reasons for me:
- It's a lot more laptop-friendly not having to deal with a mouse and complex GUI. I even gave up my desk at work and just sit and code in random places.
- On my desk at home, it's a bit faster for me than an IDE. But that depends.
- Seems like IDE users are constantly switching tools, especially when changing jobs. Even at my current 4-year job, my teammates have all changed between 3 different IDEs and had to screw around with remote access problems for each. I've used Vim everywhere since college.
Sure IDE's are great, I love stepping through code, it really helps when you're in deep and are having problems reasoning about the state of your program.
That said, every shop I've worked in used a different IDE. Possibly one picked out by some long gone coder who thought that their choice was the best.
Finally not being saddled to any one IDE lets me use the any other tool to get a job done.
In terms of searching through multiple files, I use Telescope with ripgrep and fzf. It’s an insanely slick workflow that allows me to jump around code faster than anything else I’ve used in my last 25 years of coding.
The icing on the cake is when I need to SSH into a server to debug some PHP or JS on a testing server. I know I can always open Vim for a slightly degraded (compared to my Neovim setup) but overall solid editor at any time.
I've not used it but your use case made me wonder if there's a nice way to do it, as I regularly SSH into my NAS and RPi's, so I had a quick search.
I think it is totally possible to be (even very) productive in VIM. I do think, though, that a person who is productive in VIM would be more productive if he used a proper IDE.
This is my experience after I had been using VIM for about 10 years and switched to an IntelliJ IDE (and actually learned it)
(This, of course, assumes that there is a proper IDE for your language)
What features does a "proper IDE" offer that, at least Neovim, does not or cannot provide?
Class hierarchy visualization, database schema mappings, the latest & greatest in NLP & code completion via plugins. That "just works."
Ultimately, a sufficient amount of configuration adds all those things to Vim/Emacs. Ditto VS Code on a smaller scale.
The issue is how much time.
I use all the obscure features of IDEs. Navigate to next issue, bookmarks, you name it, I've got it, for large codes.
Implementing... all... of the features Intellij/Rider provides out of the box for JVM/React stack in Vim is... an undertaking.
Don't get me wrong. I love SpaceVim, and if I worked in a domain like firmware, I'd be far more comfortable with it.
Maintaining a Vim config that's integrates every tool I need for JVM and React (and machine learning, and all the other domains) is impossible.
I'm sure I'm missing out on quality of life enhancements and whatnot, but really all of those are lower on my hierarchy of needs than staying on task.
I was coding for years before I discovered that IDEs exist. Never used one much until I started using VS Code a few years ago (if you call that an IDE, some people do and some don't).
IDE developers just keep inventing new tools. GitHub Copilot is the latest, who knows what's next?
Especially for Rust, JVM & Java. Rust without a IDE warnings is... extremely difficult. Unless you're extremely practiced with it.
As time goes on, feature parity with fully featured IDEs like Jetbrains is steadily becoming harder.
I'd readily consider a "nvim distribution" via Patreon at this point.
Configuring Vim to catch-up with Intellij is becoming a part time job.
It doesn't have to be. I tried a bunch of things but LSP-Zero just works. The UI/UX for installing LSPs and linters, etc. is better than VS Code.
As time goes on, feature parity with fully featured IDEs like Jetbrains is steadily becoming harder.
As far as I can tell, there's no stated goal by anyone involved with Neovim to reach feature parity with any IDE. That's not the point.
What's great about Neovim and similar projects: there's a middle ground between a full-blown IDE and a "text-editor".
Just because a coder/developer wants some nice things like autocompletions, diagnostics, refactoring and semantic formatting and syntax highlighting doesn't necessarily mean they must use a IDE, especially when some of the underlying technologies for providing these features (Treesitter, Language Server Protocol) are exactly the same.
It won't take long for text editor users--Vim, Neovim, emacs, Hexlix--to expect these capabilities. It'll just become the norm. Just like how most young people today know a world without the internet being everywhere, we'll have users who've never known a time when every decent text editor didn't have what old-timers call "IDE" features.
That's a perfectly fine goal.
I wrote the above in the context of so many comments saying "what's the point of an IDE."
There's absolutely a place for CLI text editors and REPLs.
I simply doubt they will ever replace the IDE as my collection of the more arcane JVM tools.
vim -S <sessfile>
I set up these items in my .vimrc to make sessions a little easier to work with:
The + key (which has a useless default role of moving to the next line) is mapped to save the current session:
:nmap + :wa<Bar>exe "mksession! " . v:this_session<CR>
:command -nargs=1 S exec "mksession! " . expand('$top/') . expand('<args>')
:let $top=getcwd()
I want sessions to be created in the top directory, rather than the directory of the current buffer.
I actually have in normal mode ,ss for save session and ,so for opening them. Central location of session dirs and that's it. Save session saves everything from files open, positions, tabs, you name it.
There is a certain organizational aspect here that I think is important to emphasize: the given paradigm is that vim is a text editor forming one part of the design environment. Assembling this environment inside a tmux session is particularly easy and powerful. And plugins can add some quality of life.
In addition, I also like the vim-slime plugin. All this does is facilitate sending lines/regions/blocks to a REPL (or in principle, any tmux pane). It's similar to the tmux send-keys function described in the OP.
A different paradigm of vim use is growing in popularity, which is the transform vim into a full IDE on its own.
(I imagine from your comment that you are probably aware of all this already)
I really like the "PDE" term - it gives us a simple division: IDE is when program ships all components by default (hence the "integrated" in the name), PDE is when you yourself attach components of your liking (hence "personalized").
It certainly does these things different than your average IDE. Again, you could argue for a long time about what is or isn't an "IDE", but merely "editor" really does injustice to some of the more advanced features in Vim because it can do so much more than just "edit text", and "IDE" certainly seems a lot better of a fit than "editor".
I also don't like the common paradigms like having a cockpit of information in my face at all times. I want the information that I need magnified and the ability to dig into it with intentionality in whichever way I choose.
When working with text, I want text in the forefront, not widgets and GUIs. Those are some philosophical, but also pragmatic reasons for prefering the shell based tools and Vim. If there is a visualization that is better conveyed graphically then yes, I can of course open tools for that purpose.
Luckily I'm able to use Vim for my workflow, but I totally get that it's not always possible or feasible.
Still, after all these years it's Tim Pope's plugins and fzf that make my editing experience so quick and fun. I could live without the rest, but an honourable mention goes to LuaSnip.
I patched bufexplorer.vim with this:
if !hasmapto('BufExplorer') && g:bufExplorerDisableDefaultKeyMapping == 0
nnoremap <script> <silent> <unique> <Leader>\ :BufExplorer<CR>
endif
Bufexplorer lists the open buffers one per line in a window that is searchable. The window can be sorted by recently used.
Switching among buffers with plain Vim is a paint: using :ls to list buffers, and :b <number> and such. A more ergonomic buffer switcher is a must.
Wow, I've been using :Ack for years and have always found that behavior rather annoying. I had no idea about :Ack! -- definitely going to remember this one.
- Show in Breadcrumb to show the package name > class > function in the top of the editor
- Open Call Hierarchy to show all places where a class/variable is used.
- Show Type Hierarchy to show how a given class is derived from Object.
- Debug Shell for running snippets in the debugger.
I know that I can use grep or ag for some of them, but I rather prefer to see the hierarchy as shown in Eclipse.
The treesitter context plugin (https://github.com/nvim-treesitter/nvim-treesitter-context) provides the package/class/function info at the top and the LSP gives you features like 'find-references' and 'go-to-definition' you can bind to the keys of your choice.
I use 'gr' for 'find-references' and 'gd' for 'go-to-definition.
I don't use a debug shell (I use a tmux pane and a repl usually) but I'm certain there are options.
I'd love to sit down with a vim expert for a day and see how much of my workflow I could replicate.
It sucks. For instance, when you're editing a .git/COMMIT_EDITMSG, it makes the directory .git/. It has no concept of intelligent exceptions.
I made myself a better one:
On startup, we save the current (i.e. project top) directory in the `$top` variable:
:let $top=getcwd()
:au BufWinEnter * exec "lcd " . expand('%:h')
:au BufWinEnter * if expand("%") == "" | exec "lcd $top" | endif
:au BufWinEnter *.git/* exec "lcd $top"
Because Vim interpolates $-sigiled environment variables in more contexts than regular variables! I can use $top pretty much anywhere.
Or at least the ecosystem that you could choose your tools to help do your job, rather than be victim of the world of shit that is the (pick any) EMR