Author here. Many will be disappointed to know that I've been using VS Code almost exclusively since 2019 (with the Vim plugin of course).
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.
(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.)
Another thing: I think I use VS Code more because I spend much less time in the terminal than I did 5, 10, or 20 years ago. Everything happens in the browser now. I used to write lots of tools and services and commands for myself based in the terminal, but now web-based tools have replaced most of them.
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)
I do miss the terminal in a lot of ways. I feel a lot of nostalgia for the days when I got all my work done with just 2x2 terminals taking up the entire screen. (You could just fit them in with 1024x768 and the 8px high Tixus font.) But in 2022 it feels impossible to live entirely in a terminal unless you're in very specific areas of work.
Nobody lives entirely in terminal these days; but terminals have gotten much nicer.
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.
I think very few people "live entirely in a terminal". I've never been all that big on IRC or mutt and the like, or "do X from the terminal!"-type programs, but a huge chunk of what I do is writing stuff (code, or just plain text), and Vim works pretty well for that. I also find it works very well for managing files and such; for example a few weeks ago I took over an old Go project, and I wanted to fix some of the "if foo == false" conditions to just "if !false", as well as reformat with the newest version of gofmt, so:
for f in **/*.go~vendor/*; gofmt -w $f
for f in **/*.go~vendor/*; gofmt -w -r 'a == false -> !a' $f
I guess maybe you have some buttons for that VSCode, but this sort of stuff is pretty fast to type out, and you have a lot of control like "exclude this directory" (like the vendor directory in the example). You can also do more advanced stuff; some time ago I wanted to see how much space my qemu images were using so I could use reasonable defaults for new versions:
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/')"
Which is a bit hacky, but it's a one-time command and it prints a reasonable nice-ish table. This kind of stuff is much harder from a GUI.
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.
> But in 2022 it feels impossible to live entirely in a terminal unless you're in very specific areas of work.
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.
Admittedly I was a student at the time, so I had a lot of time to explore and make things work.
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.
Same thing happened to me since 2021, weirdly enough my VIM setup was quite close to yours. Nowadays, I'm using VSCode + vim plugin, which is kind of the best of the two worlds.
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.
Interesting, I just switched from vs code BACK to (neo)vim. For me the killer feature of vscode was remote, but imagine my surprise to see that was one of many proprietary things in the platform. And then I discovered mutagen, and that opened up my avenue for thinking about neovim again.
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.
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 get that. I used to get pretty far with tmux and using Vim to send commands to other tmux panes. But now with web-based tools, live reloading, and utils that watch the filesystem to re-run things, the terminal-inside-an-IDE approach seems fine because I don't need to switch to it as often.
I used Emacs from 2010-2012 just to know what I was missing. I liked using it and tinkering with it, but when it came to being productive, all of the tooling felt out of date and hard to use in comparison to Vim.
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 respect your settlement on VS Code. What works, works. But 2010-2012 was seemingly ages ago compared to how well the Emacs ecosystem has modernized in such a short, recent timespan. You may find it appealing again, if you're ever interested. With the work done on speeding it up via native compilation, I don't think I'll ever find a better editor for myself, personally.
I recently setup neovim with lsp, fzf and like 10 plugins in pure lua. I was surprised that it took me just a few hours. I've spent too much time fighting viml in the past and it kept me from looking at the config for like 3 years. But holy f, things have gotten soo much better. Lua for vim is.. actually good. Like I grok the apis.
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.
I've been a heavy vim user for I don't even know how long. What does neovim get me over vim? Looking at the charter page on the website, the only thing that really stands out to me is Lua.
"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?
Lua is the only difference but it makes all the difference.
From my understanding, Lua is nicer than Vimscript, this means more people will create more interesting and better Lua plugins, that can only be used in neovim.
LuaJIT is also fast.
I also recently migrated from nvim to VSCode (First with vim plugin, now with vscode-neovim plugin).
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
no, i am not disappointed at all. if anything, i sympathise with you. the older i get, the less i care about the nitty gritty detail of how should i set my editor up. i just want to install editor which detects (and installs the ide-like tooling support) the programming i use, churn some shitty code away, and be done with it. nowadays, like you, i just use vscode and vsvim. most of the time, it works and that is what matters.
Neovim has improved a lot in the last couple of years. When I initially switched to native lsp it was a giant confusing mess. There was a lot of wading through GitHub issues trying to pull enough info together. Eventually my understanding of all of the underlying machinery got to a reasonable place (and as a result I have much better control over how I set everything up), but it was a battle. Things are slicker now though.
> I've been using VS Code almost exclusively since 2019 (with the Vim plugin of course).
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.
what's your vscode setup ? people at work use it in an ad-hoc fashion and it's surprisingly messy (tabs disappearing, git interface confused), we're also looking for partial reformat and on save fixes (whitespace and such)
I would like to add my perspective to the mix, as it seems Vim pops up here every so often and commonly the discussion becomes one of Text Editor Vs. IDE capabilities.
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).
It's alway pretty fascinating to me that people can actually be productive without an IDE.
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).
> 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.
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
If you repeat the test case with no ~/.vimrc, you will notice that the lines are changed faster.
I feel pretty much the opposite. IDE's seem incredibly limiting and feature-poor compared to editors like vim and emacs, which can do just about anything.
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.
Worth noting that debuggers, which frequently have complex interfaces, are generally much better suited to GUI applications.
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.
Eh, I'm pretty good w/ both gdb and pdb (python's debugger) and whenever confronted with an IDE's debugger (or Firefox/Chrome) I instantly feel like I do when confronted with an IDE: I'm at the mercy of whatever UX this thing will grant me. Scripting will be nonexistent/unfamiliar, specific information will be hard to find, etc.
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.
I think the interesting thing with debuggers, though, is that I relied heavily on debuggers back when I was relatively new to programming (maybe the first 10-15 years or so), but once I started to feel like I knew what I was doing--and the stuff I was doing became a lot more complicated--debuggers started to feel a lot less useful and even frustrating or limiting... particularly so given that to actually make a debugger work really relies on you buying your entire project into some unified concept of how execution will happen, as the ability to step across IPC/VM/network boundaries is otherwise a pipe dream. I thereby only feel like I get value out of stepping through some code only once every year or two, and gdb is more than good enough; otherwise, I always make sure I have really good mechanisms for logging and error handling, and leave the debuggers for when I'm teaching someone how to code.
The gdb TUI with a simple config and a simple readline config from a terminal has personally done wonders for me. I get vi mode, tab completion, syntax coloring, a colored prompt and really all I could ask for.
I have aliased gdb to "gdb - q -ex start --args" and the experience is very nice.
You’ll find that most of what happens behind the scenes in vscode is available in neovim (and probably vim and emacs). The heavy lifting is done by lsps these days.
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.
Of course, both coc and lsp are your friends there. Want to change variable or function of class name or whatever? No problem. Take this piece of code and wrap it into a function, and where it once stood just place the function call? No problem. Etc.
Yes. Well, Emacs definitely can, and I have no doubt Vim can with the same tooling. For example, Emacs has excellent support for LSP. If a language server exists for your favorite language, and it supports refactoring, then so does Emacs.
I've used vim for a while now and using it isn't a point of pride, it's more that whenever I try an IDE I wonder how anybody could be productive using it.
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.
About :grep, try integrating GNU id-utils with Vim.
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.
What do either of these `grepprg` options win me? Currently my `grepprg` calls `ag` which is plenty fast for me, and it sounds like `lid` is a slightly more general ctags?
lid doesn't tell you where an identifier is defined, but indexes all the places where it occurs. A lid query is instant; it just pulls the info from the ID file without searching any files.
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:
- 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.
IMO it’s because you’re conflating vim with an IDE. But really it’s unix that’s the IDE. I’ll use vim to literally edit files, and then in an alternative tmux pane either run my tests or ‘entr’ my source or ‘rg’ to search or git —-bless or whatever…
Editor + shell + tools is the IDE. And I like that I can swap out tools as necessary.
Neovim user, so a little different. I used to regularly use GoLand for ~3 years before I made the full switch over, and am a bit of an evangelist of it.
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.
Treesitter is amazing. We have a bunch of sql strings in python and I was able to drop a couple of lines into my injections.scm to isolate them and get perfect sql highlighting within my python code.
If anyone is interested in how it works, here's the whole thing (I'm looking for strings inside a call to a text function, which is how you wrap sql for sqlalchemy).
There's a little nuance here where the thing that treesitter parses includes the """ (or ") at the start / end but because it can recovery from errors I'm not bothering with wrangling the offsets.
Although I recognize that theoretically there are features in an IDE that could be useful, every time I've tried to use one I find it intrusive and slow and frustrating and confusing. I inevitably close it in a rage within 15 minutes because of some design decision that I find infuriatingly stupid.
neovim plus a couple extensions plus some Unix command line tools are just so simple and convenient.
I was contemplating the same thing today as I was knee deep in refactoring a piece of code - I use IntelliJ and ideavim, which I find great because it also implements (emulates?) a small subset of vim plugins. I was able to finish the fairly complex refactoring in half an hour, without taking my hands off the keyboard by using a fairly strong combination of vim and IDE features. This is what works for me.
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
What is with this obsession of never taking the hands of the keyboard? I've seen it so many times and it makes no sense to me. I don't find myself limited by the speed of typing but by the speed of thinking.
There's a steep learning curve, and it's not necessary. I mainly use Vim, but it wouldn't be a big deal if I didn't.
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.
From my perspective, vim is just a tool that I picked up in college, back in the bad old days (early 00's) where good IDE's were paid and anything free was largely terrible.
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.
I suppose I agree with this, I try not to obsess over the tools too much. It makes sense to have a standard IDE and standard tools in a company. However there's always a possibility to improve. One can suggest new tools to a small circle of coworkers, or just start trying out new tools on one's own. In one workplace that has a huge Windows codebase I compile and debug from within Visual Studio, and edit either in Visual Studio or sometimes vim. When I get the chance to do explorative work on a rather standalone project I gravitate towards vim, even to printf debugging, even though Visual Studio is available. I don't know why this is, old habits, or is it genuinely more economic on some axis - for new projects at least?
You have to invest time in your vim setup. There’s a whole lot built in that you need to learn, but you also need to customise it to your workflow.
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.
This, 100%. It took me an hour the first time I configured neovim and another hour when everything broke during the v0.8 update but the ability to navigate multiple files without touching my mouse make it worth the effort. I still have to use Visual Studio for {dayjob} but the Vim binding plugin makes it (almost) tolerable.
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.
This is something I've been thinking about a lot recently, especially since listening to John Carmack interview (https://www.youtube.com/watch?v=I845O57ZSy4) and him saying that almost nobody uses IDEs at Meta.
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)
IdeaVim in the jetbrains products is really good I find. You get best of both worlds. I used to customize vim a lot, but I pretty much just use it as is now as a casual editor for editing files, especially for big files. The editor is very snappy and quick to load compared to IDEs, but on a well spec'd computer you aren't really going to notice too much (depending on the IDE)
> It's alway pretty fascinating to me that people can actually be productive without an IDE.
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).
When I need an interactive debugger, I alt-tab into a JetBrains product or VS/VSCode. The only time in my career that I wasn't primarily developing inside of vim/neovim and now Emacs was when I was working on a .NET team.
the main thing that allows me to be productive with "only" vim is, funnily enough, things outside vim: bash knowledge. search, for instance, I can usually do in flexible ways with a pipeline of commands.
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.
After 23 years now I pretty much use it as it is out of the box and still only know a small subset of commands. It has been my primary editor that entire time other than when I had to work on C# projects. I have never encountered a bug or crash in that period.
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.
This seems to hold pretty well. I've been using vim for approximately 15 years now too and my current setup and preferences are surprisingly similar to those in this post.
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’d say that vim will never be an IDE as such, because the focus is on personal configuration. Personal Development Environment is how one of the neovim contributors is half rebranding it. The things that make modern IDEs good (like LSP) at all available but you get to shape them how you want, rather than being forced into your IDE of choices way of doing things.
(I imagine from your comment that you are probably aware of all this already)
Vim will never be an IDE because it does not aim to be one. It's a text editor - a central component of development environment, but only a component.
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").
Personally I think Vim has been an IDE for at least 10-15 years now. You could argue for a long time about the exact definitions of "IDE" and "editor", but Vim can do compile-cycle, completion, finding identifiers, file browsing, spelling checking, terminal window, debugger, scripting, and a bunch of other stuff out of the box, without plugins.
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've grown tired of big proprietary software, even if it's open source. Companies like Microsoft will keep doing whatever their business whims dictate, deprecating tools, etc... I want to live in a world where I'm in control of my software instead of constantly adapting for reasons that have nothing to do with how I like to work.
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.
My setup is very similar to the one described in the post, but I switched to neovim for the TreeSitter and LSP.
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.
What that does is make the buffer explorer's window accessible just by hitting backslash twice. The \ key is the default <Leader> key in Vim. So <Leader>\ means \\.
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.
> Note that :Ack will jump to the first result in the QuickFix list by default. If you dislike this, use :Ack!
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.
I think you can get most of the first three of your requirements from TreeSitter and LSP.
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 would still love to learn vim if only for the nerd credentials. However I cannot imagine how I would reproduce the workflow to even come close to approaching my current productivity level with VS Code.
I'd love to sit down with a vim expert for a day and see how much of my workflow I could replicate.
I'd be willing to take you up on that (well, maybe an hour or so rather than a day). I feel the same about vim - there are certain workflows I have that I can't adequately recreate in other editors, so I keep coming back. I'm curious what your workflow looks like.
I use the Vim plugin within VScode. For me it's really the best of both worlds: Full-blown IDE features along with fast Vim editing. Highly recommend it!
I also use VSCodeVim! One struggle I have though is that navigating with Ctrl+d / Ctrl+u or Shift+[ / Shift+] still opens folds if the cursor lands in the middle of a folded section. Do you run into this also and/or know a fix/workaround?
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.)