The Stack Overflow blog recently published Modern IDEs are magic. Why are so many coders still using Vim and Emacs? Posts about Vim vs Emacs vs IDEs are always awkward, usually condescending, more interested in picking a side than understanding being unbiased. Comparing communities is always a tricky thing. You have to be careful to represent their ideas in a deep and respectful way and not let your biases shine through.
These people didn’t even try.
This has led users to literally turn Atom into Vim, unable to let go of the past, unwilling to fully embrace the future of code editing.
It’s this type of comfort that has kept whatever perceived war between those still using Vim or Emacs and the prospect of using IDEs going for as long as it has. It’s mental mom’s spaghetti (or insert your comfort food here). Vim and Emacs are always there for you, cozy, calm and willing. While an IDE is some weird new food with all kinds of exotic ingredients that requires tenacious and irrational picking with the fork to get it just the way you want it. The disconnect is apparent and, at this point, understandable.
I’m certain the authors don’t use Vim.1 I’m confident they haven’t researched Vim. I wonder if they have any friends that use Vim. It’s the kind of dismissal you can only do when there’s nobody you respect on “the other side”.
For that matter, I wonder if they used IDEs. Their example of an IDE, “the future of code editing”, is… Atom. Not Visual Studio or Pharo or IntelliJ, Atom.2 Atom isn’t an IDE. It’s an IDE-lite, a text editor foremost with IDE-like tooling integrated in. There are many things that are easier to set up in Atom than set up in Vim, but there’s nothing that’s really impossible in Vim, and there’s nothing either has that compares to the deep runtime code introspection of Pharo.
Ironically, IDE-lites like Atom are a lot more popular than true IDEs for reasons the article doesn’t even consider. When people talk about good IDEs, they talk about good IDEs for a language. IDEs pin down a specific part of the editor design space. If you’re using a different language, or using a language in a way the developers and God never expected, then the experience gets considerably worse. That’s why IDE-lites like Atom and VSCode are popular. You have the base text editor, a few “universal” things like git integration and intellisense, and an extension system that can add an okay plugin for any language. That doesn’t give you an optimum point in the design space. But it makes it easier for the user to move around in the design space, so they can get close to multiple divergent optimums as their needs change. There are fantastic IDEs for some languages, and good enough IDE-lites for most languages. The IDE-lite is an asset regardless of if you’re using Go or Rust or Ruby or Haskell.
I could tell you all of the reasons I prefer Vim, and such observations are eye-rollingly trite. Modal editing! Composibility! Keyboard macros! But you can emulate those in other environments. That’s why Vim extensions are so popular!
What you can’t emulate is the flexibility. The power to choose where you are in the design space, not through settings or extensions, but through direct end-user scripting. Here’s a thing I wrote last month:
function! s:MdFootnote(note) let s:footnote = "[^".a:note."]" let @m = s:footnote norm "mpmm $put = s:footnote.':' norm `m endfunction command! -nargs=1 Footnote call s:MdFootnote("<args>")</args>
:Fo foo immediately places a Markdown extension footnote
[^foo] after the current character and drops the footnote reference at the bottom of the text buffer.3 A two character command replaces fourteen keystrokes of overhead, two location jumps, and a mental context switch. I can add a footnote tag and keep writing, flow uninterrupted.
There’s no function support in VSCode. If I wanted to implement the same thing I’d have to write an extension. How is that the future?
My vim config is 600 lines. I have fixes for small annoyances. I have a bookmarking system set up in 45 lines. I have extra syntax highlighting for code snippets that are important to me because I’m doing things the original syntax maintainers never even considered. I create impromptu keyboard mappings and abbreviations and autocommands as needed for given tasks. I can move around in the design space at will.
Unlike the original authors, I don’t have a contempt for other tools. I use VSCode for LaTeX, some Python, and pair programming. And I even use full IDEs sometimes, when I’m working on a project an IDE was designed for. But I’m often off doing my own thing, working in places where IDEs fear to tread. And that’s why I use Vim. The IDE can be the “Swiss Army Knife of features” and I’m glad it’s there, just like the Victorinox I keep in my backpack. But it stays in the backpack until I need it. For everything else, there’s Vim.
This was sent as part of an email newsletter; you can subscribe here. Common topics are software history, formal methods, and silly research dives. I also have a website where I put my more polished and heavily-edited writing; newsletter is more for off-the-cuff writing. Updates are 1-2x a week with the first being public (like this) and the second (usually) being email-only.
They targeted both Vim and Emacs but I only have direct experience with Vim. I am sure everything I say here applies to Emacs, too. ↩
The article also mentions Visual Studio, but only in a quote from someone defending Vim, who is then immediately brushed aside. ↩
Footnote is the only command I registered that starts with
Fo, so Vim will recognize the prefix. See
:h usr-cmd-ambiguous. ↩