Why are so many coders still using Vim and Emacs? (2024)

Because you only need to know one tool for every type of work you do. Except for inherently graphical tasks like drawing and diagramming.

When you use Emacs or Vim and live on the command line every project has the same workflow. You don't need to install 10 different IDEs and learn 10 different workflows for 10 different projects. You don't need to go through 117 layers of menus to apply compilation options because your IDE invokes the compiler for you. You don't need to use a mouse. No googling "how to X in PyCharm" 5 minutes after googling "How to X in Eclipse".

> When you use Emacs or Vim and live on the command line every project has the same workflow. You don't need to install 10 different IDEs and learn 10 different workflows for 10 different projects.

When I was demonstrating emacs to some co-workers last week, I opened up code in three different languages and pointed out how the comments were all the exact same color. It's little things like that. And having things like hl-todo-next/previous and flycheck-next/previous-error bound to the same keys in multiple programming languages, or binding F4/F5 to compile/recompile, and that works for any command I want to run, then I can parse through error and warning messages with next/previous-error, or cruise through blocks of code with C-M-a/C-M-e. And all of this works in C/C++, Python, Lisp, Perl, etc.

I think it is the combination of consistency and adaptability.

There area huge number of interesting features and tweaksout there, and every once in a while oneencounters a useful gem. For example, I havestarted to use Unicode more heavily in documentation,and I am also a latex user, so now there isa mode which lets one enter any kind of unicodesymbol by typing the latex sybol name.

Or another, I found that syntax highlightingis neat but what is really helpful instead isto give any identifiers in functions differentcolors, which makes the data flow in the functionmuch more salient and quicker to understand -including spelling mistakes. And that works in many languages.

> Or another, I found that syntax highlighting is neat but what is really helpful instead is to give any identifiers in functions different colors, which makes the data flow in the function much more salient and quicker to understand - including spelling mistakes. And that works in many languages.

Oh yeah, I just discovered rainbow-identifiers-mode. Pretty sweet!

JetBrains products work (mostly, I will concede) the same across all their products.

Literally whether I open RubyMine, PyCharm or CLion I feel at home.

AFAIK this is the main selling point by and for JetBrains products.

Still, there seems no JetBrains for Bash, ansible(yaml), HTML, Latex, Rust (though there is a plugin), or markdown. For me, at least, those are not my daily drivers, but I do spend substantial time hacking them. Same for "frameworks" RubyMine does Rails really well, but really gets in the way when hacking on some KibaETL or Chef scripts (also Ruby, deep down).

I'm convinced this comes from the fact that IDEs have to be both highly opinionated and very flexible: supporting all of flask, django, pandas+Jupyter and ansible, properly, is tough: all are Python, all are really different. Either you turn Pycharm into something that does not work good for anyone (lowest common denominator) or you have to leave out communities.

And also need to do everything on their own (or clumsily integrate) instead of leveraging community tools and standards like, say rustfmt, xmllint or jq through "unix".

> Still, there seems no JetBrains for Bash, ansible(yaml), HTML, Latex, Rust (though there is a plugin), or markdown.

There are very high quality third party plugins for everything you mentioned except maybe Latex? HTML support is built-in for sure in all the web-focused IDEs (pycharm, rubymine, phpstorm, webstorm). I generally edit almost all my files in a JetBains IDE, heavily using the "scratch" feature.

The Rust plugin is not ideal yet, although it is officially supported so in time it will probably have the same support and quality other products have.

> I'm convinced this comes from the fact that IDEs have to be both highly opinionated and very flexible: supporting all of flask, django, pandas+Jupyter and ansible, properly, is tough: all are Python, all are really different. Either you turn Pycharm into something that does not work good for anyone (lowest common denominator) or you have to leave out communities.

Yes, some frameworks are not fully supported, which is inevitable. The most popular frameworks will usually have an official plugin. I wish more framework/language communities would take developing a JetBrains plugin more seriously.

The language plugins do usually leverage community tools when possible, but sometimes it is prohibitively expensive performance-wise.

In conclusion: Vim and Emacs do win in ubiquity for sure. It is unfortunate though that many communities only focus on getting those type of setups working well. The JetBrains IDEs are MILES ahead of what Vim, Emacs or Visual Studio Code can do with their hodge-podge of plugins that I would never trust with a context-aware automatic refactor in my life. Those editors are in fact a "lowest common denominator", and people lose so much productivity because of them.

In fact, I will consider a language "niche" until it gets proper JetBrains support for the above reasons.

I love blowing minds with using multiple major modes. IE, executable code snippets in Org, or Javascript inside HTML.

There many Emacs packages that can do this, for example:https://polymode.github.io/screenshots/

This is really neat.

And AFAIK not something that Vim does well. At least, in my vim setup, nested modes are clumsy.

Code-inside-markdown means Markdown has to support the syntax (and snippets and shortcuts etc). Or requires a entire language (or dialect) like erb being both Ruby and HTML which cannot leverage the ruby and HTML at the same time, AFAIK.

What is, or are the common vim solution for nested or mixed modes?

This is a good read written by someone who uses multi mode editing for productive reasons:

http://howardism.org/Technical/Emacs/literate-devops.html

Oh yeah, I found his http://www.howardism.org/Technical/Emacs/spreadsheet.html about org-mode and spreadsheets, yet another thing that I love about emacs and can't imagine a "modern" IDE doing as well.

> When I was demonstrating emacs to some co-workers last week, I opened up code in three different languages and pointed out how the comments were all the exact same color.

I don't get this. That is normal in any modern editor. What is so special about this?

> I don't get this. That is normal in any modern editor. What is so special about this?

So other editors have finally caught up with emacs? Nice to know. Last time I tried opening different languages in "advanced" IDEs, it was plain black lettering on white background.

To add to all these good points, also the fact that vi/emacs isn't going away on the whim of some company that comes and goes. So the effort to learn these (and any long-lived open source components) is amortized over my lifetime, not the short lifetime of a commercial tool.

Whenever I change projects or jobs I know emacs will be there as efficient as always so I can concentrate on being productive instead of on learning yet another ephemeral IDE.

I haven't even been a developer long, but I remember everyone was using Eclipse then Sublime then Atom then Brackets then VSCode. This was all within a span of 3 years.

I've been using vim for most of my career but will use other tools when pairing or working with others, the only thing I regret is not learning the intricacies of vim more.

I'm not proficient but every few months I improve more and more, and it's nice to use a tool that has been around for decades and will continue to be around for decades more.

> I remember everyone was using Eclipse then Sublime then Atom then Brackets then VSCode. This was all within a span of 3 years.

Yes. The half-life of these things is rather short. And there are few reasons to expect that this will be better with the IDEs which are currenyly touted by one marketing department or another.

In the meantime I am using Emacs since over 20 years. I can adapt it to new things (such as magit) when this is useful but it never breaks my flow.

The most important advantage of Emacs and vi are, theseare open systems, which come out of an open culture,not just "open source" but really free software, withno strings attached. Granted, open source is having itssuccesses, so companies are trying to jump onto thatbandwagon, but this has mainly the consequence that thestrings attached are less visible - like "telemetrics",inacceptable spyware, waste of attention, artificialobstacles to competitor languages / systems,unwarranted and empty hype, and so on. It is importantto recognize the tone of that, and to listen to it, andto think about it, because it can warn you beforemaking bad decisions.

Also, Emacs has top-notch documentation.While basic commands are not that hard to learn, thereis certainly a lot of stuff one can learn, so much thatit takes some amount of conscious effort to learn agood fraction of what is relevant to certaintasks. That said, Emacs also makes fantastic use of aundervalued property of the human brain, which isautomatic decluttering, forgotting and blending outthings which are not in use, like a diligent andfriendly housemaid which brings anything which youhaven't really used in the last year into the attic ;-)

But, jokes aside, exactly like learning the Linuxcommand line well, learning some Emacs is an/excellent/ use of ones time as a programmer, becausethe half-life time of the knowledge you gather is muchmuch longer than when you just learn the latestIDE. Chances are that your IDE du jour will be mostlyforgotten five or six years from now. Chances are highthat the basic command-line tools and Emacs commandsyou learn now will still be useful twenty and thirtyyears from now.

I think you may be overly generous to Emacs. When I use Emacs, it's more I need to go through hundreds of lines of others' Emacs Lisp configurations to figure out how to do the thing I want to do or spend many times 5 minutes Googling how to do <x> in Emacs. A good example of this is Elixir's helpful coloring and tab completion in its help documents. When I tried running Iex in an Emacs terminal, it just didn't work, and after Googling, it's just a mess of solutions. It literally just works in Visual Studio Code's terminal.

I forced myself to learn Emacs for a class, and it was really quite painful. I get the power of the bindings and all that, but it's really a mess of an ecosystem, and I encountered plenty of bugs. Even then, I never got things to work just right, and it worked poorly when doing things across Windows and WSL boundaries. Another thing was that any time someone used my Emacs, they couldn't because it wasn't like their Emacs.

So I've just gotten used to Visual Studio Code because I spend more time doing the thing I wanted to do than finding out how to do something simple in the editor. I add a single custom keybinding for toggling between the terminal and the code window, which can now be synced using a Microsoft account. I just install whatever extension I want (through one extension manager) and go at it. Combine this with the extremely powerful and useful extensions of Remote - SSH and Remote - WSL that allow you to use Visual Studio Code on basically any other computer with your extensions as they work on Windows, then you have a one-stop shop for development.

https://code.visualstudio.com/docs/remote/remote-overview

And by the way, Visual Studio Code can do graphical tasks: https://marketplace.visualstudio.com/items?itemName=hediet.v...

Is Visual Studio Code perfect? No. Can someone be more productive in Emacs than Visual Studio Code? Yes, but likely only if they've spent an inordinate amount of time learning Emacs and Emacs Lisp. But Visual Studio Code provides a nice balance of a single environment across languages that evolves with users' needs and basically anyone can be productive in it today.

My personal preference is to use the standard IDE with whatever language I am using, and then to default to Visual Studio Code whenever there is no such standard. I also use a fair amount of visual languages that text editors do not work for.

 Another thing was that any time someone used my Emacs, they couldn't because it wasn't like their Emacs.

You hit the nail on the head. I spent months forcing myself to use nothing but Emacs to get past the "this is unfamiliar and therefore hard" stage. My final conclusion after the experience was that Emacs is pretty powerful out of the box but it is absolutely a general purpose environment and you have to meld it to your own workflow to truly unlock its potential.

Even though I don't use Emacs these days, one thing I did keep was swapping capslock and ctrl on my keyboard. That is useful for so many other things and I'm never going back.

Any kind of set-up is done in textual configuration. And this is a major plus.That means you get quickly to see what you have configured,you can put it into version control and check it outon a different machine, and so on. This is a big ergonomicaldifference to IDEs.

As the technical foundation, it is rock-solid. Emacs isbased on lisp which has basic text manipulationinstructions implemented in native code. This makes itboth extremely easy to configure and extend it. It isalso from a time when Linux was not yet existant, Unixwas not yet universal, and Lisp machines were a thing,so it has a certain platform feeling - while alsohaving good access to the OS. It is certainly possibleto use Emacs in text mode as a login shell or as aterminal manager.

To that adds another quality of Emacs and vi,one which these IDE enthusiasts can not evenunderstand, which is that the user interfaceis incredibly stable. And this means thatsomething you have become used to willnot change and drift under your feetlike quicksand. And in the long run, thisreally saves a ton of time. That does notmean you can't change things, rather you canchange stuff under your control, like usingthe better-defaults setup.

So, it might please you to read that there is a slow but steady process to replace elisp by Guile:

https://www.emacswiki.org/emacs/GuileEmacs

And to me, this is a indication of a solid foundation: That you can swap out some base infrastructure for another when you need to, without messing everything up. (Another example is that Racket was switching the core implemenation to be based on Chez scheme, which compiles to native code).

Here is a description of the current situation:

https://old.reddit.com/r/emacs/comments/equuct/i_would_help_...

https://www.emacswiki.org/emacs/GuileEmacs#toc1

I don't follow. How is it that graphical tasks require multiple tools, but for every other type of work you need just one tool?

That seems just obviously incorrect to me.

I do all sorts of things, and use all sorts of tools. Am I missing something?

I've been using Emacs for a lot of things for a quarter of a century. Mostly programming. Or, really, editing program source code plus some haphazard IDE features I've bothered to hack in.

Emacs is definitely is not the only tool I need. It is ill suited for graphical tasks, sure, but it is also not the best tool for email, web browsing, taking notes, calendars, and a wide variety of other things.

Sure, you CAN do most of those things in Emacs, but it's not the best tool out there for any of them. Emacs is a great IDE, but it simply doesn't exist on most of the platforms I use all the time to make in a realistic contender.

Home surveillance? Password management? Backups? Website authoring? Keeping basketball scores? Managing personal photos? Learning a new language?

Literally (and NOT figuratively!) most tasks are better done not in Emacs, but some other tool. I'm not sure why this needs to be said out loud.

Yes, like a piece of paper, you can use it for any of those tasks. Almost anything can be viewed as a "text task". But it there are better tools out there for almost all of them.

> Emacs is a great IDE, but it simply doesn't exist on most of the platforms I use all the time to make in a realistic contender.

Emacs is available on Windows, Mac, and all extant forms of Unix, so... are you talking about mobile platforms?

> Except for inherently graphical tasks like drawing and diagramming

Let me introduce you to graphviz.

https://graphviz.org

Or, for the lazy, PlantUML.

https://plantuml.com/

It's backed by Graphviz, but optimized for the kinds of diagrams software people typically do. Works very nicely with org mode too!

C4 diagrams maybe ?https://github.com/RicardoNiepel/C4-PlantUML

Tbh if I was starting now, I would probably use one of those and be happy with them.

But I started using Emacs in 1992, and it still does what I need (thank you language server protocol).

Will VS Code exist and offer the same experience over a whole career?

I've watched someone struggle for literally hours in Emacs wading through dependencies to track down an issue. He then resorted to grep and kept spending time.

The same task would be accomplished in one click in Eclipse.

There is a reason why specialized tools exist.

I do not understand why this article has such a negative bias against vim and/or emacs users. Comparing an emacs/vim user and a dog that does not want to walk on grass seems gross. Even calling them stubborn, well... The authors claim that "Modern IDEs are magic". As a freelance devops, i don't code-for-a-living being a magician, all i want to do is editing text, most of the time there's no magic involved.

"Why are so many coders still using a keyboard?" Answer for yourself.

I have been using emacs for a decade, and finally settled on vi/vim because of its broader availability. Both are excellent editors. I have also used dozens of graphical user interfaces for development, but as a devops i sometimes find myself in an environment that does not support graphics.

Not having graphics at your fingertips may sound like a restriction, but it allows me to focus on my code rather than being distracted by color, hints, hovers, help, type ahead, code completion and the like. I do not need all that, i can freely speak my favourite programming language same as i can write a text without referring to the encyclopedia britannica every other word.

Final rant: i consider the bio "He's spend over 15 years as a technical writer" as sloppy as the whole article.

> The authors claim that "Modern IDEs are magic".

For me, the word "magic" in the context of program development is ambivalent at best. Often, it refers to stuff that some software tries to automate wildly, with the result that in easy cases it works nicely, without you having a description of what really happens, and in more complex cases it fails and turns into a mess, without you having any actual clue what happens. I think "magic" works actually only if you do have an interface which takes responsibility of actually everything, like an SSD firmware driver doing write layout for wear leveling.

And no, getting 2,000 lines of automated boilerplate for some mundane programming task isn't "magic".....

This presumption really bothered me too. The tone of the authors is very anti-vim without ever stopping to mention that vim can be dressed up with plugins, command line tools, unix philosophy, etc.

It appears that neither of the authors are developers... the quality of the article would have been a lot better if they hadn't stereotyped vim users so much / admitted there are legitimate reasons to prefer a text-based interface over a GUI for en editor in 2020.

I'm surprised that a company like Stack Overflow would publish such a narrow-minded article on their company blog... surely they have developers internally using vim they could have talked to...

Not to mention the condescension in calling them, right off the bat, “a grumbling shuffle of ingrained habit and stubborn resistance to change”.

Habit and sticking with something that works are, like, good things most of the time!

I skimmed through the article and there's quite a bit more of this:

> 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.

> unable to let go of the past, unwilling to fully embrace the future of code editing.

W-what?

Agreed, the word "still" and quite frankly the rest of the article shows the author hasn't taken the effort to understand why someone likes something they don't like themselves.

This could have been an article written by a windows10 user who asks the question "why are so many people "still" using linux?". New people start to use linux today and quite frankly there's a lot of good reasons to use it over the newest windows. Obviously same can be said about vim.

As the parent says, this sounds like a loadedquestion. In fact, it sounds just like som marketingdepartmetn which wants to promote some IDE is trying togather reasons and possibly features which need to beadded to some "competitor" IDE, in order to gather moremarket share. I write that because to me, the interestto actual answer to the question - why people use theseopen-source editores - seems somewhat thin.

But, as somebody who uses Emacs, why not use theattention for some Emacs marketing.

Before going on, I use Emacs mostly since about 22years. I am also occasionally using vi (mostly forsystem administration) or mg (which is a verylight-weight editor with basic emacs keybindings). I'vealso used a host of other tools, for example in somework environments there was really no other alternativethan to use Visual Studio, or Eclipse, and in some themost practical thing to use was notepad++.

So, why Emacs?

At first, and something that might be interesting tobeginners, basic editing in Emacs, such as to producesimilar results to using notepad++, is actually quickto learn. It has a nice on-line tutorial and very goodinteractive documentation. The fundamental philosophyit has is that basic text editing is modeless, that is,one uses a (possibly large) number of key combinationsto modify text, and the basic combinations areuniversal. And this is already the main difference tovi/vim, where the meaning of basic key commands alwaysdepends on the mode. Emacs does have modes, however,for advanced commands which modify different /kinds/ oftext.

Emacs supports a large number of programming languagesout-of-the-box, which includes anything you need towrite for documentation. This saves a lot of time whensetting up projects. It is also very quick to set upadditional packages and modes.

Emacs and vi/vim both are based on the notion that codeis text: They are optimized for text editing, and in myexperience this is absolutely the right thing to do. Ihad the dubious pleasure to use several systems whichuse code as kind of point of entry to some kind ofdatabase or graphical system or whatever, and theseare, universally, just a pain in the ass.

Compared to IDEs, Emacs loads and starts very, veryfast. In cases where one want it even faster and don'tneed that many features, one can use emacsclient, orthe mg editor, or, of course, vi. It is also possibleto use Emacs in a text terminal, which is invaluablefor remote work on servers or embedded systems, and italso has good support for the shell's job control:Running in terminal mode (starting with the "-nw"option), Ctrl-Z will bring you to the shell, and "fg"will bring you back to your Emacs session.

I hear chanting coming from outside my prison.

Sure, it's a soft prison, of keyboard-only specialized-interface goodness. but a prison, still.

I've heard chanting before, but this time it's different. It's louder. Could it be? I resolve to try a daring escape. If I can get this new C++ project set up properly, I might be out free! I've chosen an accomplice of good repute: VS Code.

After 30 minutes of figuring out which extension to add for the project, how to configure the build, I still haven't managed to get it working. What could be the issue? It builds fine in the IDE but won't find declarations and headers properly. The google oracle offers no help. Hey, mr. Magician: I can compile the project just fine myself in a terminal, why don't YOU read my Makefile and figure it out?

Too late, the vim guards arrive. They open my CMakeLists.txt parchment, and write "set( CMAKE_EXPORT_COMPILE_COMMANDS ON )". Immediately, YouCompleteMe whirrs to life and works perfectly. The guards drag me back in my old cell.

Oh well, it's not so bad here, at least I can focus. And it keeps the mouse away. Until the next time I hear people outside chanting "Modern IDEs are magic".

> That said, if you’re new to programming, a modern IDE could be helpful. With code completion, Git control, and even automatic deployment systems, modern IDEs are a Swiss Army Knife of features.

Just in case anyone reading here is as colossally ignorant as the writer, let me state for the record that emacs has those features. I don't use vim but I'm pretty sure it has them too. An accurate list of how newer IDEs benefit newbies follows:

1. Familiar key bindings

Biggest problem with IDEs is they are a big in-your-face hurricane of features that is often too much.

As a newbie you want to create a single-line Hello World program but the goddamn IDE wants you to create a workspace, and then within that workspace create a project, and within that project create a bunch of infests and manifests and resources and XML files, and pretty soon you're lost.

> Biggest problem with IDEs is they are a big in-your-face hurricane of features that is often too much.

This is another aspect. They suck up attention, which is a scarce resource. It is just like you start a web browser to look up some documentation, and it shows a dozen of interesting sites you might want to read because the browser developers got some money from these sites, or whatever.

Good software typically has a sparse feeling (depending on which are its intended users), in the sense that it does not distract.

But this is just a symptom of a bigger issue that they are not really friendly to the developer.

To be fair, emacs and vim suffer from other equally baffling problems for newbies. Otherwise this wouldn't be such an upvoted question on SO:

https://stackoverflow.com/questions/11828270/how-do-i-exit-t...

What is unintuitive, is the concept of modes. One, because it is a unique concept and Two because many people who accidentally end up in vim have no use for it.

Once you grasp this concept, exiting vim is one of the most intuitive actions:

* [ESC] <- This is the "modal" part, the hard part, what you probably call unintuitive.* : <- The other part of "modal", difference between commands and navigation. Also a unique concept, that is not hard to grasp, but probably hard to know that one has to grasp it at all.* quit, exit, close * Some error may show up, telling you what to do instead, E.g.* :quit!

That is all: `[esc]:quit` a series of keystrokes that make little sense when you are not familiar with some basic concepts of vim. But entirely guessable, without reading a single line of help, if you do grasp the very basic concepts.

I think we are saying the same thing.

I was pointing out that the basic concepts like "modes", "commands" and "navigation" are unintuitive. But the commands, or navigation itself is not.

And from that, I state that it is not unintuitive to "close vim" in itself. But that "using vim at all" is.

For git in Vim I use the fugitive plugin[1] and I find it's really good. If you find it lacking in any way you can always combine it freely with other plugins. For instance gitgutter[2] that shows diffs in the sign column, giving you an easy view of which lines have been added, removed or changed.

There are solutions for the others too. Neovim has for example support for the Language Server Protocol[3] that gives you code completion, jump to definition and the like.

The only thing with Vim/Emacs at this point is that you have to do some configuration and find some plugins to get the IDE features you want. For me personally, as I use Vim for everything, it's not that big of a deal.

[1]: https://github.com/tpope/vim-fugitive

[2]: https://github.com/airblade/vim-gitgutter

[3]: https://nathansmith.io/posts/neovim-lsp/

Screenshots [1]

If I had to describe it, I'd say it visually shows you your current git status and lets you manipulate it using an interface that provides a thin wrapper around git commands. It provides all the functionality of git in a convenient and discoverable way.

[1] https://magit.vc/screenshots/

> as colossally ignorant as the writer

Your bias is showing. They never said that Vim/Emacs _doesn't_ have those. And modern IDEs generally make them much more discoverable and usable.

No-one is saying that "Vemacs" can't do everything that IDEs can do - they clearly can, with sufficient configuration, plugins, and so on. But the IDEs are generally "ready to go out-of-the-box"

> Familiar key bindings

Well, Emacs user interface and key bindings are by experience much more stable over time, especially if you consider that in ten year's time, that "new" IDE probably is probably not going to be around any more.

That also means that some default configurations do not have a "modern" feel like copy/paste key bindings. However stability in the long term is important for users of a complex and powerful program, which Emacs is. And if you want, you can always change the key bindings to your liking.

There are also options like the betterdefaults package which modernize bindings and add features without breaking anyones flow.

2. More features are part of core distribution, and they're developed by focused, professional[0] teams, so they end up being more polished[1].

--

[0] - I mean primarily the sense of "being paid for it".

[1] - Well, except for Eclipse. At least as of few years ago, default Eclipse had worse overall experience than even my worst beginner Emacs configs.

It's not merely nostalgia or availability. I continue to use emacs because it has the features that I want, where other software does not.

Some things I want out of an editor:

* Never having to touch the mouse in any way.

* The ability to customize any feature for my current project or mindset on a whim.

* No UI, as much as possible. Show me the content I'm editing and nothing else.

* A good, extensible, set of keybindings with a bunch of features for editing of raw text

I run my project in an IDE and will sometimes use a feature, but I generally don't develop there.

The extensibility of Emacs is a major boon. Here an example: I never did real Emacs hacking, but I learned some Lispstuff over the years, a bit of Clojure, Racket,and Common Lisp each. Now, I have a very experiencedsenior coworker which was asking for help -there was a feature which was just not workingfor his flow, he had tried to configure it butwithout success. Now, I looked into theEmacs library code and that was a pleasantexperience, it is very transparent and readableand easy to modify, so that it was not difficultto adapt it to my coworkers's needs.

The extensibility also means that, because there aremany many people hacking on Emacs, that it stays veryup-to-date. For example, Magit which is, Ithink, the best git front-end in existence. Or there isranger mode, (ranger is a console file manger). In thissense, Emacs is not "antiquated", as the blog articleinsinuates, but it is much more recent and modern thanany IDE. Take, as an example, git support: It tookVisual Studio about fifteen years to add git support,in part obviously because the vendor company did notthink supporting git was helpful to the companiesobjectives. In comparison to that, Emacs picked upversion control options such as subversion or gitalmost immediately. As a result, Visual Studio userswere left for fifteen years without support for theperhaps most important technical advance inprogramming. You may now argue, that the "modern" IDEsof course do have support for git, but there are surelyother things which will be missing, just because itdoes not fit some companies narrative or marketingstrategy. Another brewing revolution is thatprogramming culture is drifting away from C++ and Java,in parts even from OOP, which is not any more the bestoption for every case, and companies which areinvested in these "technologies" (uh, what a word),will again try to stop the clock, in order to squeeze abit more money out of it.

I feel like you could do a single-image rebuttal to this article, consisting of a timeline of various popular code editors/IDEs that have come and gone since 1976, and how many of them are still around.

I mean, f*ck, I've only been in this industry since 2011, and that's still long enough for me to recall the "rise" of half a dozen code editors (SublimeText! Atom! Intellij! VisualStudioCode!). I imagine most people don't like re-learning their entire workflow every couple of years, and just want to get back to coding.

I'm only slightly older than Vim itself (but much younger than vi), but I've used it for virtually my whole career. The one thing the author's missing is the real reason every Vim user uses it:

Vim is not an editor. It's a language. A text-editing language.

When I'm editing, I'm thinking things like:

- change these 2 words: "c2w"

- remove everything in these parentheses: "di)"

- delete this line: "dd"

- where is this declared: "gd" (this is a custom CoC.vim mapping)

Any editor implementing that language would probably see very good adoption in Vim user circles (e.g nvim).

An IDE has some integration benefits, sure, for a relatively tiny number of languages, typically, compared to Emacs and Vim, at the cost of amazing raw editing capability no IDE comes close to. Samples: copy/paste rectangles of text, interactive regular expression replace, dynamic abbreviation expansion, edit remote files via SSH, exchange words around punctuation, treat words, lines, sentences, expressions, functions as movable units, works on a bare terminal, works via X, spawns windows on other displays while sharing the same buffers, saves multiple cursor positions, supports macros that can cross modes (open/close files in the directory browser and mod them in a single macro), and so on ad nauseam. Anyone only aware of just using arrows keys in their IDE to move around and DEL + text insert to edit is blind to an entire universe of elevated editing possibilities in true power editors like Vim and Emacs.

Emacs is my IDE. I use Vim too. Both in their native keybindings. And when I taught, I had all my Unix students learn both of them the same way. I have never seen another editor that comes even close to them for power of raw text manipulation. Got one?

> copy/paste rectangles of text, interactive regular expression replace, dynamic abbreviation expansion, edit remote files via SSH, exchange words, ..., saves multiple cursor positions

Most of the popular text GUI editors (VS Code, Sublime Text, etc) can do these things.

> treat words, lines, sentences, expressions, functions as movable units, works on a bare terminal, works via X, spawns windows on other displays while sharing the same buffers, supports macros that can cross modes (open/close files in the directory browser and mod them in a single macro),

These ones not so much, but then you also give up quite a bit by being in a terminal, having to deal with modes, etc.

> Most of the popular text GUI editors (VS Code, Sublime Text, etc) can do these things.

Yeah but Emacs could to that twenty years ago. Picking up git support in Microsoft tools took more than fifteen years, I think. The same will happen with upcoming useful new features and techniques, just because they do not fit some companies marketing and product strategy. Does one really wants to be that much behind with useful features and tools?

Why wouldn't we use them?

- FOSS, That means we don't have to pay money to be allowed to code by somebody else

- Available everywhere, even in terminals

- Low resource usage, so I have more available for the other tools I need to use (browser, chat, vm, compiler, streaming...)

- Fast, they are extremely fast at editing code, with low latency

- Easy to extend, at least Emacs is, you write a function in a file and boom, done

- Feature rich, at least for some languages like Ruby there is nothing commercial editors offer you that you don't already have, or 99% there

- No mouse needed, so my wrist does not hurt anymore.

- No spyware, seriously, why do I have to disable google anlytics in my code editor, and keep an eye out in case an update re-enables it

And the "price" you have to pay to use them? Just learn their keybindings, literally what you have to do in any code editor as each has their own, just that these two have more, and they're quite different compared to what you might already know.

Note, I've tried out many editors over the years: Visual Studio, Notepad++, Eclipse, Netbeans, Intellij and it's language specific clones like WebStorm and RubyMine, Sublime, Atom, VSCode, pure Vim, pure Emacs, and now finally Spacemacs. Only the last one managed to fit the bill for me perfectly, being feature rich, fast, and it stood out of my way when I needed to focus.

If they dissapeared over night, it might surprise you, but I would go back to Netbeans, for the same reasons, as far as I'm concerned, giving me just enough functionality and then staying out of my way when I need to do my work is what I value the most in them.

That being said, I acknowledge both Vim and Emacs have their quirks and baggage, but so do the others, and I preffer to deal with learning Vim movements compared to staring blankly at a screen until I remember where to click through menues.

My advice, use all of them, but take it seriously, dedicate x > 2 months to each one you would like to try and use them intensively, learn as much about their capabilities as possible. At the end choose what works best for you. And don't just use something because somebody else tells you (or makes fun of you because you're not on the latest trend). You are you, not them. It might not be what I would choose but why do you, or I, care?

> Why wouldn't we use them?

On an individual level: learning curve, company policy, integrations to dev ops flavor-of-the-week and the initial difficulty to extend the editor.

With that said, learning Vim is a good way to get exposure to a very different type of user experience in software. Plus, you may see an increase in productivity. I don't see that increase, but I at least gave it a fair shake 10 years ago.

My increase in productivity was because of the auto completion feature from Sublime that I could not turn off, I found myself typing two letters and then waiting half a second for the drop down to appear so I could select the word. When I tried making a Jupyter notebook for a presentation I was planning and tried to type code there I realized: "I don't know the syntax, because I never needed to learn it. If I present like this I'll look like someone who doesn't know how to code". Was really ashamed of myself at that point.

So I forced myself to write code in Vim without any plugins for two weeks until I could type fluently. I was in insert mode most of the time, and did not use hjkl movement naturally, but it worked wonders, I could write words without interruption, my thoughts flowed freely.

Then I tried switching back to Sublime and felt less precise. Like vim was this stone path I was walking with confidence, and Sublime this fluid river I needed to row a boat on. Also for some reason I noticed that when using Vim, my wrist would feel lighter, while switching back to Sublime and using a mouse my wrist would suddenly gain "pressure". That's when I made the switch to Vim permanently and started customizing it. Only switched to Emacs, and later Spacemacs due to poor "Find and replace in project" functionality.

Besides what's everyone has said so far, what I love the most about my emacs is that the only thing I have on my screen 95% of the time is code. No side file tree, though helm find files has a sweet UI I use hundreds of times a day. Magit is there in three key strokes and out when I'm done giting. My window navigation is sweet. Sometimes I have zero splits, sometimes I have a dozen, and it's easy to navigate between each split, resize them, undo split modifications etc. My flycheck shows me errors in a great UI when I need it and doesn't show when I don't. Same with helm-imenu that that shows me classes, functions, methods and attributes when I need them and only then.

I'm sure you can do that with all the editors, but when I see peeps using VScode or myself using Xcode, everytime close to 50% of the workspace is filled by stuff I only need temporarily.

Emacs let's me see code most of the time, yet has all the classical IDE features one could dream of. <3

I'm using Emacs since 10+ but the one thing that never worked for me is window switching with more than two windows. Do you use C-x o to switch between multiple windows or what do you use?

That's what I currently use to switch quickly:

 (use-package ace-window :defer t :init (key-chord-define-global "ii" #'ace-window) :config (setf aw-scope 'frame))

Try this:

 (use-package window-numbering :ensure t :config (window-numbering-mode))

This will rebind M-1 through M-0 to become window-switching keys, and also display each window's number in the modeline. I've been using this for years now, and haven't found anything else that beats the speed of pressing M-1 through M-5 with my left hand (I rarely have more than 5 windows per frame).

Yes, I use ace-window as well: (global-set-key (kbd "M-o") 'ace-window)

Combined with maximize-window and winner-undo, I'm in heaven :)

You can also use WindMove, built into emacs (https://www.emacswiki.org/emacs/WindMove) and use Shift, and arrow keys to move from one window to the other.

Not OP, but I’ve had same difficulty switching among windows.

I remap “other window” shortcut to something more convenient. See https://emacs.stackexchange.com/a/3471

I use vim because it’s the only real option for my workflow. I work on an extremely large codebase that easily eats up several hundred GB of disk space.

This code lives on a workstation under my desk. I do my coding on a laptop.

I want only one feature: Low latency for typing, find/replace, search over a wireless connection from my laptop to my workstation, possibly while I’m traveling.

Nothing beats ssh’ing into my workstation and launching vim. (Emacs will also work - I just prefer vim because I’m used to it)

I would love to use an IDE and the powerful features that come with it. But I wouldn’t trade off latency for those features.

Additionally, there are a ton of people who use the same workflow as me - ssh + vim. Any impact from changes to a network security policy will quickly be fixed because it impacts soo many of us.

I use ripgrep[0] to look for things. It’s incredibly fast - I have found that it’s usually faster than what an IDE takes on a much smaller project.

Once ripgrep has found something, jumping to that file is super easy (and fast!)

I use ctags on smaller subdirectories when I’m not familiar with the codebase and I need to jump around a lot to find definitions within a small number of files.

[0] https://manpages.debian.org/testing/ripgrep/rg.1.en.html

> I use vim ... I work on an extremely large codebase

That's surprising to me - it's usually once I get up into the triple-digit file count that I give up on command-line tools and start letting an IDE index things for me.

For me, I've been using Emacs for 20 years. It comes down to two things:

 1. I never have to move my hands from home row. Pretty much anything I need to do, I can do in Emacs (including file browsing, PDF viewing, web browsing, music playing, git, shell stuff, etc), and faster, because I can rebind keys at will. Emacs is just too darn flexible. 2. Anything good from other editors will eventually make it into emacs. The first thing that comes to my mind is snippets which I think came from TextMate. Again, emacs is just too darn adaptable and flexible.

That said, I don't recommend non-programmers or even new programmers learn emacs. It's a steep learning curve, it's just I've already climbed it, and now I delve even deeper to learn more about it whenever I can. I just don't have the technical investment in any other editor, and it's highly unlikely that any other editor, IDE, etc will ever have enough advantage to switch.

Edit: Ooh, I just remembered this one: I'm not a big user of TRAMP, even though it's awesome, but it's even more awesome than I realized. A couple of weeks back, I was test-compiling and running our codebase on a new version of the OS, using a remote machine via ssh (forgot the -Y). I quickly found myself missing the M-g n and M-g p for moving through compile warnings and errors, so I loaded a remote edit session on my local emacs and without even thinking just ran a compile. To my wonder, it just Did What I Meant, and ran the compile on the remote machine, no special setup required! I mean, it was utterly seamless. It's this sort of thing that keeps me learning emacs and just marveling at how awesome it is!

> To my wonder, it just Did What I Meant, and ran the compile on the remote machine, no special setup required! I mean, it was utterly seamless. It's this sort of thing that keeps me learning emacs and just marveling at how awesome it is!

This will blow your mind then (as it did mine, when I discovered it): it also works like this for GDB sessions.

> That said, I don't recommend non-programmers or even new programmers learn emacs.

Emacs is definitely more useful to people who use it somewhat frequently, as one has to memorize some key strokes. But, there is a good interactive tutorial, and I don't think that learning Emacs to the equivalent of a beginner's level of competence takes very long. A few afternoons perhaps, and one can go extending from that.

And if you forget things, it is because you do not need them that often. This is also a kind of economy in there. Maybe other things are more important.

> Why are so many coders

It is unclear how many coders do in fact. There's a very LOUD subset of programmers that absolutely do, because they'll tell you they do every chance they get. But if you only listened to the comment section on sites like this you'd think that nobody uses Visual Studio, IntelliJ, Eclipse, etc rather than them being more stereotypical for professional shops than Vim/Emacs.

If you look at Stackoverflow's survey[0] it gives you some idea, but because it is a [Select All that Apply] question it can inflate IDEs that are good for occasional/general purpose usage (e.g. Vim, Emacs, Notepad++, VS Code, etc). They should ask people what IDE they use MOST.

It is the same thing as Windows, you come to any programming message board you'd think 99% of programmers use Linux professionally, but in the corporate world (which is the majority of programmers) Windows rules the roost.

[0] https://insights.stackoverflow.com/survey/2019#technology-_-...

IDEs are one of the biggest barriers to programmer development, flexibility and knowledge. They try to insulate you from your actual environment and encourage lazy practices and thinking.

I learnt java in eclipse and it was dreadful. Code completion stops you learning, IDE errors and auto fix stops you understanding compiler errors. build shortcuts stop you understanding how javac and maven builds work.

In short they take all of the available deep knowledge your programming language and environment, hide it from you and then pretend it's a good idea to replace this with a load of superficial knowledge about how to click the right buttons in some bad software.

Another advantage of Emacs compared to IDE isthat it is resource-friendly, on multiple levels.

Foremost, it is friendly to the resource whichhas become the most precious one, which isattention. It has a sparse interface which showsexactl;y what is needed. Compare that to a newlylaunched Edge browser which will show you totallyinappropiate and distracting yellow press contentwhen you start it.

It is also resource-friendly to screen real estate,making a good use of the text space. Granted, largescreens did become more affordable in the last tenyears, but while attention is still a scarce resource,programs also did become much more complex, and, alas,your eyes are not going to increase in resolution,they will become worse in the course of yourwork life, which makes the screen space even morevaluable.

Emacs is also economical in terms of learningeffort - the basic editing is simple, andyou can focus attention to the things thatyou use most.

Compared to that, IDEs are cumbersome. They arecumbersome in terms of modification, requiring endlessdeep menus which are nowhere documented, and notgoogle-able, they have built-in build systems whichwill support only a few languages, they have complexnon-textual interfaces, which are just a hassle, theyforce you to use the mouse, which in Emacs is entirelyoptional. I also think they support, in part, badpractices in coding. If you really need an AI andautocompletion to produce working code, I am not sureyour code is that good for humans to read - and thisis the most important aspect of code. It not only needs tobe writable, it needs to be well readable.

> It's less a war at this point than a grumbling shuffle of ingrained habit and stubborn resistance to change.

That is just silly.

I have VSCode and the JetBrains IDEs on my desktop, but Vim is _everywhere_ I work - even Windows servers if desired. If I'm working on a server, or another workstation, I can use a common editing environment.

There is nothing stubborn about it, consistency is powerful.

That's exactly the point; the very first section header is:

>Vim: The high availability IDE

I've been programming for 10 years now and I've never understood the hype on the internet about vim/emacs. No one I've known at the university or in 5 different software companies that I've worked at used vim/emacs as their primary code editor. Vi was used sometimes to change a config file or to inspect something while SSH-ed into a server, but IDEs have always been used as the primary ways to write source code.

I've mainly worked with Java, JavaScript and Python. I started with NetBeans and Eclipse for Java at the uni, but soon moved to the JetBrains stack (IntelliJ IDEA, PyCharm, WebStorm). Everywhere I worked people have been using mostly IntelliJ, some of them VS Code recently.

I tried learning vim properly, memorizing the shortcuts etc. I had several attempts at this throughout the years. Mostly because of articles like this one, hyping vim/emacs. But I always felt it slowed me down soooo much. Modern IDEs allow me to edit code, jump though files, classes, methods, variable usages, rename all usages of a class/method across the whole codebase sooo quickly!

And almost everything works out of the box. I don't have to install plugins or configure anything to have syntax highlighting, git etc. I import a Gradle project and IntelliJ knows everything.

I do get the argument from one of the comments that this isolates you from how javac/maven works under the hood, and that it can be bad. But throughout the years you'll learn those things eventually. And in the meantime you don't need to master them to be productive.

I completely don't get the comments that you need to constantly Google things like "How to do X in Eclipse". Some of them you do need to Google, but most things are straightforward. Meanwhile when working with vim I kept constantly Googling things like "how to replace a word", "how to copy a line", "how to delete a line"...

To sum up, I agree with one of the comments that said that it's the vocal minority that keeps talking about vim/emacs that makes it look so ubiquitous. In reality I feel like 95% of programmers use IDEs for most of their work, get their job done and don't talk about it. That's why it looks to be the other way on the internet.

I started programming in the days of punchcards. Since that time I have tried more editors and IDE's than most people: ed, teco on teletypes, XEDIT on IBM 3270 terminals running on IBM Mainframes, CDC 6600 editors running on the Kronos OS, the editors on the University of Illinois Plato system, TextMate, Sublime Text, Jetbrain's IDEs, Eclipse, Xcode, Visual Studio and VS Code, and countless other less important editors and IDEs.

The idea that I use Vim and Emacs because I don't know better is simply uninformed. I use Vim because no other editor connects my mind so directly to the code I am working on, as fast as I can think of where I want to be in the code or where I need to make the change, I am there and made the edit with just a few keystrokes.

I use Emacs because of its phenominal collection of packages: org-mode for writing text, outlines, interactive agendas, literate-programming; magit for git, auctex for composing LaTeX, tramp for editing remote files over ssh; dired for viewing and organizing my directory contents and hierarchies. In addition to the hundreds of commands and built in packages there are over 4500 contributed packages that provide amazing facilities. All of this in a self documenting, fully programmable system.

I pay for a subscription to the full set of Jetbrain's IDEs, they're great and worth far more to me than the much more expensive Adobe subscription that I have but use very little. PyCharm and CLion are great tools, and I've done most of my recent Java using IntelliJ. However, for writing code other than C++ and Java, I find myself most comfortable in Emacs.

I believe that I could put together the right set of packages to make C++ or Java development on Emacs a satisfactory choice, but one of the weaknesses of Emacs is its programability and extreme flexibility--at some point you have to stop sharpening your axe and start chopping and here having a Jetbrains IDE definitely pulls ahead.

> Modern IDEs are magic. Why are so many coders still using Vim and Emacs?

The title answers the question to some extent - I prefer Vim over IDEs because I am allergic to "auto-magic". Also, unlike most IDEs, Vim will still be there after 5 years, 10 years, or 15 years.

I feel the same way. The beauty of Vim is that it's not onlyflexible but also respects the user; unlike most IDEs it doesn'tblindly make assumptions, auto-format code while it's beingwritten, auto-close brackets and tags, it has no "plugin XY hasa new update!" popups. It just reacts to input and nothing more.

Vim can have most of those things if needed, but after years ofusage my tolerance for "smart" features declines constantly.Which in turn made me gravitate towards using more CLIutilities, as those follow the same philosophy and go hand inhand with Vim. The "no automation but efficient shortcuts"approach just feels more reliable and predictable.

An old coworker (Vim user) of mine had a good response to another coworker who asked him "why don't you use an IDE?":

"I do, it's called Linux."

There is common name for that, "unix as an ide"

I often point people to this blog when asked why I don't use an ide

https://sanctum.geek.nz/arabesque/unix-as-ide-introduction/

Knowing a bit of emacs has helped me a lot when fixing code on servers via shell.

I also think that while learning, writing code in an even more primitive editor (editor.exe) could prove beneficial.

But apart from all that, being a self-taught programmer, the JetBrains IDEs (pycharm, rider, IntelliJ) have significantly improved my skills and saved me tons of time by highlighting potentially problematic lines (“you are using that iterator twice, be careful!”). It has made me research topics I might have taken hours to find out for myself. It encourages frequent and easy renaming of variables and functions across the whole project, which has allowed me to be more flexible and maintain sensible names for things even after changes. It encourages consistent naming, too. It makes navigating code throughout the whole project a breeze. And basically any of the gazillion of features can be assigned a keyboard shortcut.

Plus, if I’m spending 8h every day staring at code, I rather look at a UI nicer than the command line tbh., but that is a matter of taste I guess.

Also, something is to be said for being “able” to use a shortcut, and “having to”.

> It encourages frequent and easy renaming of variables and functions across the whole project, which has allowed me to be more flexible and maintain sensible names for things even after changes.

This one is really a good thing, I agree. Which seems to require a language server integration package for Emacs - AFAIK there exist two of them by now.

What I want from an editor:

1. no code completion -- rarely works well. To get it to work well, it requires set up, and when I start a project, I don't want to waste time setting anything up. Also, doesn't work for interesting things, like code generation. I realize most programmers rarely do anything like that, but I do.

2. Customizability -- emacs is super-customizable. Lisp is easy to understand and you can basically do anything.

3. No mouse -- I'm faster just using keyboard shortcuts

4. Runs in terminal or graphical -- When I ssh into a machine, I want to be able to use Emacs through the terminal

5. Orthogonal user-interface -- In Emacs, everything is a buffer. I can use the same interface to navigate through Emacs 'configuration' as I can through my code. I can use the same interface to navigate through the Emacs terminal emulator as my code as well. This is amazing. Contrast this to 'newer' editors like Sublime or Eclipse, where the configuration dialog, git interface, etc, are all custom UIs. To understand why this makes a difference compare and contrast the experience of using a Web-based App via a browser to the feeling of using a Native App. The native app may 'feel' nicer when you look at it, but nothing beats the consistency of the browser interface (back button, copy/paste integration, links, etc.). There's a reason HTML based interfaces are so popular

6. Universal support -- emacs runs on basically everything. So does VIM (Probably more than emacs)

7. Support for large numbers of libraries, languages, etc -- I've rarely found any new language, framework, etc, which doesn't have support in Emacs. With some changes to my init.el, the package is installed (thanks to use-package), and I'm done.

8. Easy dot files -- I have several computers. To set up emacs on a new computer, I just copy my .elisp directory.

In other words, the advantages of Emacs and VIM over other editors are:

1. Text-based interfaces2. Universal support3. Customizability4. Adherence to the UNIX philosophy (everything represented as text)

> whenever people describe their reasons for using them in lists like this, I see nothing that I would consider an advantage over my current setup, and then just forget about the whole thing.

TBF, you've just described exactly how us emacs and vim users feel every time someone says "why aren't you using shiny new editor X? It has feature Y!"

As an emacs user who has used a few IDE's in my time, some nice things you might be missing (but which you may not care enough about to switch):

 Easily recording and playing back macros. Delete-rectangle / insert-rectangle Undo tree Jumping backwards/forwards a whole word with a keypress. Can be run inside terminal, when a command needs an $EDITOR

Thank you.

1. Notepad++ has macros when I need it.

2. Rectangular selection is available is VSCode and I use it a lot. The generalisation, multiple cursors (with each cursor having its own clipboard), is the best thing since sliced bread in a text editor.

3. I don't have undo tree, I can see it being useful sometimes. Hope it appears in VSCode soon [1]. Fequent automated backups (file history) works OK as an alternative.

4. Ctrl+left, ctrl+right jumps a word in every editor in Windows. In VSCode you can also jump a fraction of a word (to an underscore or the next part of a camel case name).

5. Well this I can't do but never needed to.

[1] https://github.com/microsoft/vscode/issues/84297#issuecommen...

Ha, I actually all three of Vim, Emacs, and a more IDE-like editor:

- Vim: this is my home editor - in particular, I use Vim keybindings in the other editors. Mostly I use it for editing config files and other scripts, and occasionally to perform more complex editing tasks in files I'd usually use other editors for. I have a good configuration for editing these sorts of files. I have tab completion, project search, and the like set up here, but not more complex language-specific editing functionality for the most part.

- Emacs: for Org mode and Magit primarily. I'll edit other files here if it's convenient (especially if I'm editing a file linked to by my Org agenda) - I use Doom Emacs, so there are some sane defaults installed for other languages - but I probably won't adopt Emacs as my primary editor, since it's prone to lag and lock up too often. Maybe that's due to Org, and I could fix it, but since Emacs' support for multithreading and async isn't the most robust, it seems like a better of use of my time to leave Emacs dedicated to Org mode.

- IDE: At Google, there is a web IDE that is integrated with syntax checking, build system, source control, that I use most of the time to edit code that goes into Google's main repository. I've briefly tried to set up such integration with Vim and Emacs - they exist, but it hasn't been worth my time when a frankly pretty good solution is actively maintained internally.

Perhaps I would use VSCode if I were working elsewhere, assuming its plugins are more robust than Vim/Emacs language integration plugins. The Language Server Protocol has been a boon to all the editors I use.

What I like about Vim is that it has a limited set of features out of the box. As a result, I feel that I have a strong understanding and command of Vim. If I want an additional feature I can either add it myself or look for an available plugin. With plugins I usually go through an adoption period where I try to determine if the benefits of the added features outweighs the loss of total understanding of my setup or any degradation in performance. In other words, I enjoy that Vim is an onion with few layers.

In contrast, modern GUI IDEs are more feature rich out of the box, but at the cost of tool complexity. Simple workflows are generally easy to get working, but adapting the tool to a complex workflow can have me clicking obscure options on the Nth option page without an understanding of what I've just done to solve the issue. As someone who works on a variety of codebases, tinkering around with setups for each project can (a) become a serious time sink and (b) can increasingly make me feel like I don't understand the tool if each setup seems to be relying on disjoint sets of new-to-me configuration options.

Additionally, I personally feel that "magic" utilities can rob me of my understanding of languages and codebases. It helps me rest easy at night knowing that I can create a codebase from scratch without needing to rely on "Create new C++ class ..." and automatic refactoring features provided by an IDE.

Regardless of my preference for Vim, I have found that a distributable configuration for a modern feature-rich IDE can be an invaluable asset for open source projects. Being able to open an IDE, load a configuration, and press the build button can remove significant barriers for contributing to projects where your understanding of the codebase and build system are nonexistent.

After 10+ years of Eclipse, Vim, Atom, and IntelliJ... I've bet on Emacs over the past few years on the basis of https://en.wikipedia.org/wiki/Lindy_effect and that it holds a unique space in computing re programmability: https://martinfowler.com/bliki/InternalReprogrammability.htm...

The authors mention "With code completion, Git control, and even automatic deployment systems, modern IDEs are a Swiss Army Knife of features.", perhaps without realising that:

* code completion has been standardised via LSP (e.g. https://github.com/joaotavora/eglot works great, and is planned to move into upstream Emacs )

* Emacs has great Git clients (Magit, vc-git)

Diversity of tooling shows we're experimenting. Good!

vi/vim is my editor of choice because the shell (ksh or bash) is my primary IDE.

The last 20 years or so has required me to develop mostly scripting (ksh, sh or bash) that is executed by some sort of automation. The shell is where I spend most of my time executing commands that need to be scripted, inspecting various system resources and troubleshooting. The vim editor is readily available to use in places where external tools outside of a terminal emulator may not be readily available or the startup time required to configure those tools may be better spent on configuration tweaks in the shell.

I've also found especially when working with build automation in Jenkins or deployment automation with uDeploy, that a GUI-based client IDE somewhat obscures things I need to see in the environment I am building in. IDEs like Eclipse and IntelliJ IDEA, while providing plugins for Gradle or Maven, may have configurations that are not compatible or differ in some fundamental way from those of the server build environment.

"They must like manual screwdrivers, we've had electric drill-drivers for years!"

What he doesn't seem to realize is that Emacs is more like a tool chest than a tool.

As soon as you go from the generic "mechanic's tool set" or "homeowner's tool set" to a toolchest you've created with all your screwdrivers in one drawer in plain sight, and your wrenches in another...

You know the immediate productivity boost of just going and getting what you need directly.

Most real mechanics add tools to their tool chest for specific jobs they've done, and common jobs start migrating the tools closer at hand.

This is all done organically and good experienced people can do things quickly and efficiently (and it works at any employer, cross-platform)

Doesn't mean these folks can't use visual studio or xcode. Or fix a flat on the side of the road with the tools that came with the car.

Answering the title question as written:

Because IDEs are a trap. Skills wither.

Whenever I find a spelling error in a variable or field name duplicated hundreds of times throughout a code base, I know an IDE has been there before me.

I find plenty of spelling errors with VIM users.

It mostly comes down to who has spellcheck on and pays attention to it.

I personally love vim, and have found that setting up vim keybindings for my IDE seems like the best of all worlds.

I do appreciate the consistency and speed of plain vim, however I can't fathom trading that for code completion, which in my experience is the biggest missing feature from vim. Even with plugins like YouCompleteMe (which is awesome) the completion quality isn't even close to what you get in a real IDE. I'm honestly curious how people code productively in a professional environment without code completion?

I’ve spent 20 years in vim, Emacs, and various IDEs and I’ve come to the conclusion that nothing is more powerful for editing text than Vim’s interaction language, no system for text editing is more powerful and easier to customize than Emacs, and some languages really benefit from an IDE.

So: I use Emacs with EVIL (vim emulation), and for Java I switch to JetBrains IntelliJ, also with Vim emulation turned on.

Like a woodworker who builds their own tool bench exactly how they like it, a programmer needs a toolset that suits them and that they understand intimately. Yes, you can get a bench from Lowes and maybe save some time, but in the long run you’ll be better served by the one you built.

Where the analogy breaks down is that a woodworker can customize an off-the-shelf bench pretty easily, but a programmer has a much higher barrier to customize/build plugins for an IDE. On the other hand customizing Emacs (or Vim, but I think Emacs is much easier to dig into) is trivial, and with a bit more effort writing really advanced customization that script your editor for whatever you need is pretty easy. If something breaks, in your code, an installed package, or the core editor, you can just debug it with a first-class built-in debugger.

I often have project-specific code to e.g. spin up my current job’s integration test environment and run the test I’m looking at. Could I do that in Goland? Probably, with enough effort. But I can keep using the same tools I’ve used for 20 years to do it.

If you’re interested in getting started I would recommend Doom Emacs to a new user these days.

I'm stuck 50km from my workstation with my code on it, which company policy dictates cannot really leave the corporate network, and even if it could it takes a specialist workstation machine with 40+ cores 20-30 minutes to compile it, but 3-4 hours on the HP Z2 mini I have at home.

So I have to work remotely, and the latency of remote desktop is abhorrent, so a graphical IDE is out.

Also CLion, which I normally love, simply can't index the massive codebase. VSCode can, but VSCode frankly doesn't compare.

So even before working remotely I started using emacs with lsp-mode. Which is fine because I have been a casual emacs user for 30 years now so my fingers work efficiently in it, and the LSP stuff is fast and competent. It indexes everything I need and has pretty good symbol navigation and even some simple refactorings.

(I'm a paying CLion customer, but JetBrains can't seem to get their act together with large code bases. Many years on and the Chromium tree simply can't index in it, let alone the tree I work on which is Chromium + an extensive set of internal trees)

I use vim, with only the dumb auto-complete, because it forces me to take it easy, to get a more complete mental model of the area of the code I'm working on, and, if it becomes too tangled to keep in my head, the tool won't save me and I'm forced to rethink that part of the program.

It forces me to concentrate a bit more, to focus and achieve a state of mind that I enjoy a lot, where I feel close to the code, at peace, focused.

Back when I started programming, I was using windows notepad, then UltraEdit32, Ms Visual Studio, then on Linux Code::Blocks and Eclipse, and it's so awesome how they can look into the structures and tell me the properties on the objects, but on the other side, it removes the friction of writing ugly structures with too many badly named properties.

So I moved to VIM relatively late.

I dunno, it just gives me a different level of peace and understanding.. It's also practical because I can work over ssh and with tmux, and vim does have nice text-editing capabilities, though I'm often not using it to it's full potential.

The article mentions how our fingers are the bottleneck in turning though into code, maybe those guys are brilliant, or maybe they write too much code, I like to spend time on each and every line, not just pound away like a crazed monkey like I did in my teenage years, I like to consider each line I write, and examine it together with the lines around it and the functions around it and the objects around it, does it fit in, does it feel right, does it perform well.. This takes a long time for me. Maybe I've turned into a bad programmer..

I used to easily monkey 5-600 lines of code out per day, but now I write maybe between 10 and 200, but I find them beautiful and satisfying, almost every one of them, and I feel I've weighted my options for everything I make, and that is very satisfying to me, it gives meaning to my day and makes me want to continue doing what I do.

>> Maybe I've turned into a bad programmer

I agree with you on everything except this ^^ :-P

I too enjoy that sort of mental model you are forced to get into, especially in terms of translating that simplicity and focus into a codebase. Not just being a “hero” and cramming out code, then having velocity and feature progression suffer years later for the known (and unknown) tech debt generated from not thinking things through with patience and consideration.

Same here, this makes it easy! https://github.com/VSpaceCode/VSpaceCode/

The critical piece for me is which-key: it displays available keybindings as-you-type (inspired by the Emacs package of the same name) – https://github.com/VSpaceCode/vscode-which-key

Back when I was working on Google's indexing system, we had a test-driven-development evangelist work with our team for a few weeks, helping get us up to speed with the latest best practices. He also kept strongly recommending we switch from Emacs/Vim to Eclipse, telling us how wonderful it was. Several of us tried it out. Our next meeting, we asked him what we were doing wrong that it took so long to start up, and was still a bit laggy for several minutes after starting up. He told us that it was re-indexing our code in the background at startup, and that we should really just start Eclipse on Monday and keep it open all week.

At my current job, I use IntelliJ off a local install, and the startup time is painful compared to Vim off a network drive, and the UI gets laggy from time to time. It has some git integration, but if I switch branches, it takes IntelliJ tens of seconds to catch up. The auto-complete is also sometimes handy, but I almost always need to add a trailing token and then go back to the token I want auto-completed to prevent auto-complete from swallowing the existing trailing token. The way I work and the way IntelliJ likes to auto-insert close-quotes, etc. quite often ends up incorrectly closing something that's already closed, assuming I'm always editing code left-to-right. Sometimes, IntelliJ also gets into a state where it seems it has hit a race condition between parsing and editing code and it thinks my code won't compile, but it in fact compiles fine and restarting IntelliJ fixes the mis-parsing.

The code indexing and auto-complete is handy, but it certainly feels like I'm both doing something wrong and have my setup a little off. The UI laginess across both Eclipse and IntelliJ across more than a decade, running from a local drive, even on a pretty beefy workstation, is easy to get used to, as long as you don't frequently switch to an editor that isn't laggy.

On the flip side, I imagine if you're very used to auto-complete, it really messes up your workflow to go without it, and even more disruptive to switch back and forth between editors with and without auto-complete.

I’m addicted to Emacs. I think a key part for me is that while for an individual task I can often find a better IDE, there is no one IDE that covers anywhere near the range of things I use Emacs for.

It’s the Swiss Army Tool. Not perfect for any one job, but good for almost anything.

I use VIM to edit individual files not associated with a project. Code, notes etc. It makes me feel like a hacker from a Neal Stephenson novel, or cyperpunk film. It's fun.

If I'm working on a coding project, especially in a statically-typed language, hacker text editors are hard to justify compared to a Jetbrains IDE: The latter have a powerful understanding of the language you're using, and use it to catch errors and suggest things as you type, refactor, jump to definitions etc. I don't think there's any plugin combination for VIM, emacs etc that's on Jetbrains' level of language integration.

Everything aside from semantics-aware refactoring(I think) andsome details in syntax highlighting can be achieved by Vim,Emacs and any modern editor thanks to LSP. For example I cancode in TypeScript with real-time code checks, semanticcompletion suggestions and error messages similar to what'spossible with IDEs.

That doesn't mean I don't start up an IDE now and then to workon certain projects, but it's more the exception when necessary,as it always feels very cumbersome in comparison with weirdbehaviour everywhere.

I'll add to the cacophony and say that my journey has been IntelliJ (when I was in college learning Java) -> VSCode -> Spacemacs (w/evil mode) -> (Neo)Vim

Over time I've been getting more and more drawn to the trinity of lightweight, control, and reduction of noise/overhead. I don't like having things that I didn't specifically require/install/configure. I really appreciate the philosophy of starting at stock vim, and then add configuration/tools when you realize you need/want them. [ And of course, vim keybindings can't be beat ;) ]

Every IDE I've ever tried is slow. That's literally it for me. I do use VS Code quite a bit for more complex refactorings, but I do use vim for quick edits to files + initial development.

Edit: should say, I also do a lot of work on remote Linux boxes, often supercomputers. Vim is the only thing I can guarantee is installed - Emacs often is not.

stubborn resistance to change

Ironic, given the recent trend of making everything out of bloated browsers, like every new IDE out there.

I use terminal Vim mainly because of tmux and all of the benefits that come along with using it.

Being able to split projects up by sessions, persisting everything and seamlessly jumping between varying layouts of terminals and code editing is something I haven't been able to reproduce with any other editor (even if it has a built in terminal).

These are like interactive programming languages / environments that you will use to interact with your computer and with text files. It is convenient, once you have learnt them.

I will wonder how a programmer would interact with the text on computer regularly without convenience of these tools.

I recently learned vim (a couple years ago) and will never look back. Going back to VS Code every once in awhile to make sure I’m not missing out and I don’t, lol

Onivim is VSCode and vim built in ReasonML. That’s the next best excited thing for me

IntelliJ is probably the best IDE out there but it doesn't even support C/C++, even with plugins.

That's all the reason you need. It's why I switched back to vim.

I was recently given some money and splashed out £150 on an i5-6th gen desktop which lives in my roofspace. The i5 replaced my trusty dual-core.

A long time ago I centralised my projects to the headless roofspace box and now run up Sublime remotely for each project (using lxc). It works great and I can code from any computer on my network.

This seems easier to me than running vim and spending a month getting on top of my vimrc.

because 45 years worth of polishing makes a nice thing, my hands have spoken that thing since i was 15, so bite me?

more to the point: why does anyone care, as long as my stuff’s done in time and doesn’t sh*t all over the coding style or formatting guides?

In the early nineties, when we were coding on Sun Sparcstations, the only real options were vi and emacs. I'd tell new college grads to use vi. After a few weeks I'd tell them about the existence of emacs.

Some would switch, most never did.

Nobody was forced to use an editor against their will, but before ubiquitous Linux availability in college, it's not as if they had any practical Unix experience.