Modern IDEs are magic. Why still use Vim, Emacs? (2020)(stackoverflow.blog)
stackoverflow.blog
Modern IDEs are magic. Why still use Vim, Emacs? (2020)
https://stackoverflow.blog/2020/11/09/modern-ide-vs-vim-emacs/
13 comments
I'm someone that started out on fancy IDEs roughly 10 years ago, switched to vim roughly 6-7 years ago, and then switched to GNU Emacs roughly 4 years ago. At this point I'll probably only switch away from Emacs if it is to another Emacsen, ideally one Scheme based (I have even toyed with the idea of writing this myself). Happy to answer any questions about the each and my transitions.
Similar story: started on IDEs (to wit: Netbeans) roughly 13 years ago in 2011, started using Vim around 2013-2014, switched to GNU Emacs in 2019. Other than Netbeans I've used IDEA and Eclipse for Java development; but I just love Emacs. It's so nice to be able to tell my editor what to do when I need it to do something and to be able to teach it to do what I need.
I'd love to use Emacs for Java development, but I feel that IDEA is almost a necessity for professional Java/Spring development
I think lsp integration[0] can get you pretty far, but also if you use LLM features a la Copilot, I use ellama[1] for that. If there are other features you think you will miss, maybe I can ease your mind about those as well :)
[0] https://github.com/emacs-lsp/lsp-mode
[1] https://github.com/s-kostyaev/ellama
[0] https://github.com/emacs-lsp/lsp-mode
[1] https://github.com/s-kostyaev/ellama
I used Eclim (https://github.com/emacs-eclim/emacs-eclim) for a bit, but I'm guessing, like the sibling comment said, that the current preferred solution would be to use LSP.
I'd love to know if this was in a work setting. Did switching have any effect on your productivity? I appreciate that some languages are better suited to Emacs such as lisps and schemes.
What prompted the transitions for you?
What prompted the transitions for you?
I switched from IDEs to vim in school. That was not much of a challenge for my productivity. I didn't spend a ton of time configuring it or anything like that, and because it was vim instead of vi, I was able to ease in to the controls instead of being force to use hjkl movement right away. Eventually I did learn hjkl as well as lots of other bindings. I have actually lost a lot of my vim muscle memory though.
I don't think the transition to vim was a very conscious decision. I just started using it more and more until it fully replaced my IDE usage. Switching to Emacs was a conscious decision, and one that I took on during work, after college. I wanted to switch because I was interested in learning Lisp, and that seemed like the gateway to me.
I tried switching to Emacs a few times, and it did not stick with me one less than a few times. One of the ways I was able to make it work for me fairly early on in my transition was to use the Spacemacs distribution. I was working on a Flutter / Dart application at the time, and that came with a more IDE-like environment that was more convenient than using vim. What made it really stick for me though was eventually learning Scheme through the OCW SICP lectures with the intent of getting into GNU Guix. Right now Guix is my primary distro of choice, and I use it very heavily in conjunction with Emacs (I use Guix to manage all of my Emacs packages and config). The SystemCrafters YouTube channel, website, and git repos were a huge resource for me for my current configuration.
I don't think the transition to vim was a very conscious decision. I just started using it more and more until it fully replaced my IDE usage. Switching to Emacs was a conscious decision, and one that I took on during work, after college. I wanted to switch because I was interested in learning Lisp, and that seemed like the gateway to me.
I tried switching to Emacs a few times, and it did not stick with me one less than a few times. One of the ways I was able to make it work for me fairly early on in my transition was to use the Spacemacs distribution. I was working on a Flutter / Dart application at the time, and that came with a more IDE-like environment that was more convenient than using vim. What made it really stick for me though was eventually learning Scheme through the OCW SICP lectures with the intent of getting into GNU Guix. Right now Guix is my primary distro of choice, and I use it very heavily in conjunction with Emacs (I use Guix to manage all of my Emacs packages and config). The SystemCrafters YouTube channel, website, and git repos were a huge resource for me for my current configuration.
I was mainly using the now sunset Atom (VSCode forked from Atom) back in school and a little bit Emacs 28 when using terminal.
With the built-in custom it is not too difficult for me to make the switch after Atom got killed by Microsoft. I can't imagine how difficult it must have been back then for new users before the easy customisation features. It is a good decision by the maintainers. I probably would have gone for VSCode otherwise.
Org-mode is also another killer feature that I chose Emacs over VSCode. Now I do work management, literate programming, and typesetting via LaTeX in org-mode.
With the built-in custom it is not too difficult for me to make the switch after Atom got killed by Microsoft. I can't imagine how difficult it must have been back then for new users before the easy customisation features. It is a good decision by the maintainers. I probably would have gone for VSCode otherwise.
Org-mode is also another killer feature that I chose Emacs over VSCode. Now I do work management, literate programming, and typesetting via LaTeX in org-mode.
Now that I have been using Emacs as my main editor for a few years, I can't really imagine my life without org-mode.
Really it is just too good of a feature, if for somehow I have to switch in the feature, my number 1 requirement would be feature parity for org-mode (extremely unlikely). AFAIK, none of the "magical" modern editors have that, except the most basic org file text editing functionality.
Really it is just too good of a feature, if for somehow I have to switch in the feature, my number 1 requirement would be feature parity for org-mode (extremely unlikely). AFAIK, none of the "magical" modern editors have that, except the most basic org file text editing functionality.
When I first switched I mainly rely on easy custom, with minimal lisp code. However, a few issues:
1. many popular packages did NOT implement for custom (e.g. by declaring with defcustom), especially those that are not in MELPA.
2. the built-in customisation is NOT efficient, especially on startup
3. The customisation UI is sometime buggy, especially for themes.
So I ended up switching to configuration with straight + use-package + org-mode after Emacs 29 got released for a while. I done some GC optimisation as well and this made my Emacs startup gone from ~5s to ~1s, also much smoother response in general.
So I ended up switching to configuration with straight + use-package + org-mode after Emacs 29 got released for a while. I done some GC optimisation as well and this made my Emacs startup gone from ~5s to ~1s, also much smoother response in general.
Incidentally, I stumbled upon this post a few months ago and was deeply frustrated by it. The depiction of anyone who doesn't use this author's preferred tool for text editing as stubborn backwards idiots too set in their ways to change, who simply don't know what this author's favorite tools could offer, reeks of condescension and hubris. It also ignores that many people switch from IDEs to things like NeoVim and Emacs, so it can't just be people who've been using those editors for years and are too set in their ways to change — although I'm sure this author would have a snide dismissal for those people too, like accusing them of being hipsters that "just want to seem cool and hacker-like."
Meanwhile, the reality is that many of us who use these text editors are fully aware of the power that IDEs can provide. For example, I regularly use Android Studio for Android app development precisely because, for that kind of extremely complex build system and heavyweight language and framework, with that much boilerplate and that many forms to fill out, IDEs are hard to beat.
But, and this is what this person ignores, IDE do come with trade-offs: greater complexity, resource usage, higher lag and startup times, and inferior pure text editing tools (and no, a vim plugin won't help). Most importantly, with a full-on IDE, you typically lose a whole lot of flexibility — IDEs typically are much less configurable and adaptable to different workflows and new features, or even just various customizations that a user used to a regular text editor might want to make. IDEs are also typically highly coupled with the language and the build system they are designed for, such that they typically only work for a specific language or two. If you regularly use multiple languages for your job or hobby projects, then if you wanted to use a full-fat IDE, you'd have to install multiple versions, or somehow wrangle the IDE into supporting all of those languages simultaneously, which is a difficult prospect. Not to mention that it would be awkward and burdensome to attempt to use a full-fat IDE for something like word processing or note-taking because of how targeted they are at a specific language and its build environment, whereas a classical text editor is great at those things, because that is part of what they were designed to do before WYSIWYG word processors came along.
Meanwhile, in comparison, a text editor like NeoVim or Emacs can be equipped with 70% of a full IDEs capabilities through things like (using emacs packages here just because it's what I know) vterm, magit, treesit, lsp-mode, and dap-mode, as well as per-language modes for the build system and such if needed, and in return, even a relatively slow and heavy weight text editor like Emacs will give you less resource usage, better performance, and much greater flexibility, both in customization and in the ways that you can use it. And you can see that this is something that plenty of people actually want, instead of just some stubborn and dyed in the wool people who've been using vim or Emacs since the 70s or hipsters that want to use something old school for cool points, because there are plenty of brand-new IDE-lite text editors, like Visual Studio Code and Zed, that people flock to in huge numbers! I certainly think if anyone uses vim or emacs completely vanilla with no completion and code actions and stuff like that, they may in fact be just a stubborn old timer, but that isn't the majority of people using either of those editors anymore, most use them as an IDE-lite experience just like VSC.
But most importantly, I think what the author of this post is fundamentally missing is that not all languages require a heavyweight IDE: in some languages and build environments you can reach productivity equivalent to an IDE user's just using a standard text editor, if your build environment doesn't require the equivalent of filing and submitting a stack of tax forms to function properly and your language isn't the equivalent of bureaucratic legalese. The full power of IDEs is only really made necessary by a certain type of problem and environment that isn't universal. IDEs are like huge, powerful construction equipment, sometimes you just don't need something like that.
Meanwhile, the reality is that many of us who use these text editors are fully aware of the power that IDEs can provide. For example, I regularly use Android Studio for Android app development precisely because, for that kind of extremely complex build system and heavyweight language and framework, with that much boilerplate and that many forms to fill out, IDEs are hard to beat.
But, and this is what this person ignores, IDE do come with trade-offs: greater complexity, resource usage, higher lag and startup times, and inferior pure text editing tools (and no, a vim plugin won't help). Most importantly, with a full-on IDE, you typically lose a whole lot of flexibility — IDEs typically are much less configurable and adaptable to different workflows and new features, or even just various customizations that a user used to a regular text editor might want to make. IDEs are also typically highly coupled with the language and the build system they are designed for, such that they typically only work for a specific language or two. If you regularly use multiple languages for your job or hobby projects, then if you wanted to use a full-fat IDE, you'd have to install multiple versions, or somehow wrangle the IDE into supporting all of those languages simultaneously, which is a difficult prospect. Not to mention that it would be awkward and burdensome to attempt to use a full-fat IDE for something like word processing or note-taking because of how targeted they are at a specific language and its build environment, whereas a classical text editor is great at those things, because that is part of what they were designed to do before WYSIWYG word processors came along.
Meanwhile, in comparison, a text editor like NeoVim or Emacs can be equipped with 70% of a full IDEs capabilities through things like (using emacs packages here just because it's what I know) vterm, magit, treesit, lsp-mode, and dap-mode, as well as per-language modes for the build system and such if needed, and in return, even a relatively slow and heavy weight text editor like Emacs will give you less resource usage, better performance, and much greater flexibility, both in customization and in the ways that you can use it. And you can see that this is something that plenty of people actually want, instead of just some stubborn and dyed in the wool people who've been using vim or Emacs since the 70s or hipsters that want to use something old school for cool points, because there are plenty of brand-new IDE-lite text editors, like Visual Studio Code and Zed, that people flock to in huge numbers! I certainly think if anyone uses vim or emacs completely vanilla with no completion and code actions and stuff like that, they may in fact be just a stubborn old timer, but that isn't the majority of people using either of those editors anymore, most use them as an IDE-lite experience just like VSC.
But most importantly, I think what the author of this post is fundamentally missing is that not all languages require a heavyweight IDE: in some languages and build environments you can reach productivity equivalent to an IDE user's just using a standard text editor, if your build environment doesn't require the equivalent of filing and submitting a stack of tax forms to function properly and your language isn't the equivalent of bureaucratic legalese. The full power of IDEs is only really made necessary by a certain type of problem and environment that isn't universal. IDEs are like huge, powerful construction equipment, sometimes you just don't need something like that.
[deleted]
[deleted]