I find this and the emacs sentiment really weird. I use vim daily for quick edits, but for any sizeable codebase, especially new/unfamiliar, IDE's are just better. It's like depriving yourself of a bunch of tools and helpers for no visible benefit.
Each was going to kill Emacs.
Somehow, I think I'll be using a version of Emacs until the day I can no longer type.
Meanwhile, everyone else is wasting months getting up to speed on the latest and greatest thing every 8 years or so.
This adds up over a career.
Oh, and by the by, this was written in Emacs using GhostText as the link between Firefox and Emacs.
Yeah I used to think this way, because you're right: becoming proficient in emacs takes significant effort and time.
But becoming proficient in VS code takes maybe 25 minutes. 25 minutes to change IDEs every 8 years or so doesn't seem like an onerous requirement to me.
Emacs just has extremely poor defaults and out of box UX.
Becoming proficient in kicking a ball takes 5 minutes. Becoming proficient in football takes slightly longer. Magit alone makes VS Code look like a child's finger painting.
Magit is indeed a great git client, but I don't see what that has to do with emacs having bad defaults and an out of box experience that could be charitably described as antique.
When you've been using the same thing for 20 years changing defaults to be trendy isn't a plus.
You'll understand in 20 years when you're on your 4th IDE which will change the world^tm.
And it also means obsolete.
>You'll understand in 20 years when you're on your 4th IDE which will change the world^tm.
How condescending.
But no, I probably won't mind changing editors every few years because I am capable of learning new things and do not require a safe space to keep me insulated from the outside world.
So there is nothing wrong at all with switching to a new editor… it just means things are getting even better!!!
He's right about the defaults though. Use something like Spacemacs or Doom if you just want to dip your toes in the goodness that is Emacs.
One header read: "Not better enough". Inasmuch as Visual Studio Code does anything better than Emacs, it doesn't do things better enough to justify expending the high activation energy of switching, unlearning my Emacs workflow and learning all that I need to know to do things Visual Studio Code's way.
Recent research has confirmed that this is an actual phenomenon: https://link.springer.com/chapter/10.1007/978-3-031-35017-7_...
Discussed on Hackernews: https://news.ycombinator.com/item?id=36721055
If IDEs help you work better, that's great. Do not presume your experience and preference generalize to all.
The one exception is maybe untangling particularly gnarly git conflicts.
Not really my thing but I guess it works for them.
There's no way to unify it given how many different moving parts are involved. Trying to fit this all within an IDE would be a project of its own...
* rg with telescope window to quickly find text in very large code basis is essential.
* Pressing spc, spc, to bring up a telescope window of my open buffers and typing in text to narrow them, very important.
* To date I still struggle to get the LSP to work the Linux kernel on VSCode, but on Neovim I got it working.
IDE's have a lot of menu clutter that I struggle to make good use of-most programmers working on user-space apps, it is likely fine, but for the kernel, we often need more control.
First I've heard of this. As a long-time vanilla Emacs user, I'm using consult-ripgrep and rg-project for ripgrep interfaces, consult-buffer for fast buffer and file switching, Eglot for LSP integration (mainly with clangd), etc. I've also got org-mode for note taking, magit for speedy Git manipulation, etc.
And all without any visible menus or clutter.
I suspect that a power Emacs user and a power Neovim user are more akin here to each other than to VS Code users.
Spacemacs got me into mnemonic key bindings, but it was too buggy and development had slowed. I got some things working with Doom Emacs, but it had a lot of bugs as well. Part of that reason is projectile also seemed to no longer be worked on. They were converting over to project.el but that seems to be slow.