It's crazy that here in 2023, Emacs is still the absolute beast when it comes to developer productivity. I had a colleague review one of my workflows the other week and after a minute or so he said "Whoa, I would have been in 5 different tools by now".
If you're not into Emacs, I suggest you give it a whirl. For most development, nothing else will get you close to the joy and productivity that a well configured Emacs can.
Well, that's the real issue for me. I spent a month an a half working on "configuring" NeoVim. I got it to a somewhat ready to use state for my usual workflows. But I still had a big pile of tasks in my backlog to actually get it finally 100% mine.
Then I discovered Helix, which doesn't need any configuration, no plugins to play around with. Builtin LSP, Builtin Fuzzy Finding of files, TreeSitter and the list goes on.
Even though it's still not fully checking all the boxes I need to have a 1 to 1 mapping of my previous workflows to what Helix offers. I find not having to build my own editor out of the Lego pieces and always needing to improve what it can offer me, makes the editor actually enjoyable.
IMO, VIM, NeoVIM and Emacs should start looking into implementing a bit more than just the barebones, some of these new features that people are accustomed to in 2023, and more and more will flock to these good editors.
I'll admit I didn't look into it, but Helix sounds like something like LunarVim (https://www.lunarvim.org/)
Personally I much prefer that the editor NOT ship with something like that by default, especially when it's so easy to set up. I have several different vim config I use, including a pretty bare-bones one for headless systems, and I much prefer the ability to customize something very specifically.
Build tools that can compose together, rather than a single do-it-all tool. That is the power of the low level editors vs IDE's.
You can still leverage the power of low level editors, just like helix does, and still have access to important things that so not require pages upon pages of configuration and plugin stitching to just get up and running in most projects you want vim or emacs like editing capabilities.
Helix is different from Lunar in the sense that the features it comes with are part of the core editor and the editor still feeling like an editor
a few years ago (~2018?) I got excited about trying Org, and installed Doom Emacs on my (~18mo) old rMBP and it was slow-to-unusable. After ~30m of unproductive debug, i went back to vimwiki. The onboarding even with a distribution can be problematic.
I recently made some big changes to my Emacs config to incorporate new tooling like LSP into my workflow. It turned into quite an extensive change as I re-evaluated many extensions and replaced some with newer alternatives. Took a few evenings.
But I hadn't touched my config for three years before that! I've been using Emacs for 15 years and you definitely get to a point where you don't need to tweak it every day. 3 years is the kind of time some people would switch to a completely new editor. I have, in a way, except it still supports all the workflows that have become familiar over the years.
I installed spacemacs 5ish years ago and have added maybe 20 lines to my configuration since then. None in the past 4 years. It's really overstated the amount of maintenance that Emacs requires.
How is that true at all? I started with plain Emacs and gradually updated the configuration to the level of polish I wanted. Even if you're impatient and want something modern up front, the advise given is to start with a starter pack like Doom Emacs.
a huge part of it I will say is antithesis to current state of programming. Emacs is literally a live elisp interpreter with everything in global scope. You literally replace parts of the application in runtime.
As a long time emacs user, I can’t describe enough how much I love VS Code over emacs. And yes, I was a power user with all the fancy modes. And yes, I work entirely with Linux.
> "Whoa, I would have been in 5 different tools by now".
And those 5 tools would likely beat Emacs in their individual area.
At the end it's all a tradeoff between low fringe with somewhat good enough performance, or high fringe for stellar performance. Sometimes you need it, sometimes not.
I would say magit as an example. Single key presses for most actions. I often have that situation, when I share my screen and perform some commits and then people ask me whether I already commited X. I then think something like: "Uh, but I just did that, in front of your eyes." but then I remember the other workflow involving the normal command line or some clicky-gui kind of tool, that is just slower and is what others are used to.
Then maybe keyboard macros. Define anything you can input in a "tiling" way on your keyboard as a macro to let the editor perform it repeatedly. Approximate quote from coworker: "Sometimes you do things inconveniently, but what you do in Emacs was highly efficient."
Then running vterm inside emacs and searching and copying from the vterm buffers to use text elsewhere.
Of course org-mode as an extremely neat way of managing information and to do. I use it every day, a lot. I use it for notes, for to-do, for time tracking, for literate programming, for devops, for creative writing, and probably more.
Then the pain I get, when I see people closing their vscode, just to reopen it in another directory ...
Then the pain I see others have, when juggling a high number of editor tabs in intellij or vscode, instead of buffers that exist and can be switched to using keyboard shortcuts. I lost faith in tabs for code editors.
> Then the pain I get, when I see people closing their vscode, just to reopen it in another directory
> Then the pain I see others have, when juggling a high number of editor tabs in intellij or vscode, instead of buffers that exist and can be switched to using keyboard shortcuts. I lost faith in tabs for code editors.
That my biggest beef with VScode and IntelliJ. Why on earth I can’t have multiple projects open and switch between them as fast as in Emacs / Vim with Tmux
Other than that I could somewhat live with modern editor, but I’m switching constantly between 5 different projects and VSCode solution to have single workspace makes navigation an awful experience
Magit is probably the easiest one for casual devs to appreciate.
"M-x magit" get a nice list of the status of the files in the current branch.
After you mark which ones you want to keep by moving up and down pressing s(tage) u(nstage) you just press "c c" and write your commit message. Then you press P and your git repo is up to date.
At a previous job the head engineer flagged the number of commits I was making as an issue since I must be wasting a lot of time pushing incremental changes. When I showed him that it took me about as long to push changes to my branch as it did to save the file he was flabbergasted that one could use git without pain.
> "M-x magit" get a nice list of the status of the files in the current branch.
Except it will randomly split your frame and show up in a seemingly arbitrary location - often obscuring what you're working on. I find the whole layout system in Emacs completely chaotic. I guess it comes with the flexibility (VS a fixed system like most Ides) nor do I have any particular solution in mind
I'm curious if anyone has tamed the weird inconsistencies of how new frames (or is it windows? Can never keep the terms straight) pop up. For instance a CIDER error buffer shows up using some completely different black magic than magit
There is definitely a system to it. Something like "split at the longest side of the current window" or so. I have developed a feeling for where my magit buffer will show up. 95% of the time I am right and my eyeballs already move where it will appear. Anyway, if you want to get rid of some window/undo a split: C-x 0.
To be honest I've never played with this part of Emacs. The way I use it I'm fine with the default. But if not it's possible to take control of Emacs internal windows management.
I have my Emacs setup to never split anything and just use the whole frame (window). That also goes for things like helm. Instead of splitting I prefer to open multiple frames and let my window manager, manage them. This really improved my workflow.
thank you !
I'll see how it goes. Hope it won't be too wonky.
Ex: In Magit when committing it now first shows a "changes" buffer that you have to kill and then you can get to the buffer where you write the commit message. Not a biggie but prolly breaks the original UI design
In addition things other people have mentioned, like magit, I would add org-capture as a good example. Let's say I'm busy at work in a buffer and a thought comes to mind: "I could refactor that other module using this code". Instead of doing it immediately and breaking my flow, I press C-c c, select "todo", type "refactor that other module", perhaps add a tag, a category etc. then C-c C-c and it's filed away.
What's really important about all of this is, it's all Emacs. Every magit buffer, every org-capture buffer, it's all just Emacs buffers and they're all configured the way you like. If you need to do a regexp find and replace while you're capturing a note, you can. If you make a typo in a note, in a commit message, in an email or anything else, it's spell checked and you can correct it with the same key you always do. This integration is the real magic.
Can you share details of your experience with org-jira? My question would be: Is it feature complete? Does it allow one to do everything one can do in browser Jira? Set custom fields, handle multiple boards and so on?
In this particular example, I was documenting my investigation into a defect. I was jotting down notes in Org-mode (1. note-taker). Those notes included SQL scripts which evaluate directly in the note-file (2. ejc-sql / replacing dbbeaver), letting the next user see which result I got from the queries and the ability to re-run the queries (C-c C-c). Some of the results returned large jsonb blobs, which were made readable with M-x json-prettify (3. replacing some online json prettifier). The git stuff (branching, making a pull request, updating it) was handled using Magit/forge (replacing git/lazygit). And ofc the code-editing replaces (5) whatever IDE you could otherwise use.
I saw people (in their 30s) using emacs for almost everything. Coding, reading mails, organizing their todos and so on. It was impressive to see their workflow.
Nit: It's a proper noun "Emacs" unless you're maybe referring to the executable "emacs", but at any rate the eMac was a computer sold by Apple in the education sector, and eMacs is the plural of that. Your iOS device is likely autocorrecting to that spelling, because to Apple, what else could you possibly be referring to?
In 2018 I switched from Vim (used for 5 years) to Emacs and I have no complaints about RSI/CT. It may be because I also learned to properly type with Dvorak at the same time. Unlike most Vim switchers I don't use Evil because modal editing just doesn't work for me. I always find myself having to change mode to do something and half the time the mode change doesn't take and shenanigans occur.
> The only thing which hold me back to really learn it, were the stories about repetitive strain injuries
Without wanting to be a troll, that's exactly what happened to me within 3 days after switching to emacs.. So I reluctantly terminated my emacs experiment early and switched back to vim..
You definitely needed to be on evil-mode or a framework (like Doom) based on it. The key bindings with ctl, alt, etc. are the least important part of Emacs but sadly, the part everyone thinks of first...
At the time I was thinking that if I had to change something as fundamental as the key bindings to get it to work, it was maybe not the right tool for me, as these base bindings were probably a key part of the whole Emacs philosophy that I would then completely miss-out on..
But if you say that they are the least import part of Emacs, I might revisit it when I have the time. Thank you for the tip.
I feel like beginners should not read things like this. Just use the tool as little customised as possible, and be comfortable with it. Then look at making it more comfortable or more capable. If an enthusiast starts you down the customisation path up front, it's surely overwhelming.
When I learned emacs I just learned the tiny handful of motion commands: fwd, back, up down, by character, line, paragraph, code unit; plus opening and saving files -- basically the same power of Atom or Sublime or such. Then because of how emacs works I'd learn a new command from time to time and wonder how I lived without it. Even now 45 years later, I learn a new capability every few weeks, though of course Emacs is a lot more capable than it used to be!
A book like this is great, of course, once you're already comfortable with it.
Year after year I find myself using vscode instead of emacs for almost everything. Until org-mode support in vscode improves, I'll keep using emacs for that.
I keep trying VS Code, but I hate how when I split the screen three wide ("splits") it wants to open "editors" in each of the columns, even if it's the same file. I want a "buffer" like Emacs has that can be called up into any of the "splits" without reopening the file.
I disable the tabs display, but when I visit a file in each of the three columns (i.e. what in Emacs would be calling a buffer into a window) I end up with the same file open three different times, once for each split. Then the fast switcher just gets full of dupes. BLAH!
I really wish VS Code used the Emacs model of completely disjoined (a) buffers, (b) windows, (c) frames, but instead there's a hierarchical approach of Splits -> Editors.
I've dug into VS Code issues about this, and it seems the hierarchy between Splits -> Editors is a strong parent-child relationship embedded deeply within VS Code's model and is unlikely to change.
While Emacs is opinionated in its own way, it is extremely configurable, programmable, modifiable, customizable to ones needs. I guess it will take a long long time, until vscode is as modifiable as Emacs, if ever. And maybe that is not vscode's goal anyway.
VS Code's goal is to get the low-effort 30% of devs who want something that will just work right out of the box, while providing enough functionality/customization to attract a significant fraction of the remaining 70%. And given that, it's pretty good.
But I'm skeptical it will ever be as good for someone who does want to make the investment in something like Emacs.
This is my final quibble with VSCode as well - except I'm coming from Vim. I've hunted high and low through the settings - if anyone from the VSCode team is reading this, there's not another feature that's more vital to match vim/Emacs utility!
I'm a long time vim user who tried Emacs for a good few months. I started out with a minimal config and just got used to it out of the box, and over time evolved to using something more like evil mode and packages for everything.
The things that drove me back to vim were basically:
- Poor mercurial support. Monky is supposed to be like Magit but lacked support for staging individual hunks or any of the hg evolution commands. This forced me to use terminal modes which...
- ...The terminal modes are absolutely atrocious half baked pieces of crap. The only advice I really got on this was that using the terminal modes is "not the emacs way".
- I found it to be very opinionated about the style of C code I was writing. It tries to automatically indent things in very specific ways and god forbid you want to change the level of indentation of a block. You can change the way emacs indents your code in your config, but again, god forbid you ever want to do something slightly different to your config.
- Working with panes (windows), buffers, tabs etc. is a pain. You close a buffer and it disappears from the screen and is actually still open, and it pops up again when you wanted to go to something else.
This sounds like a bad review but I did for the most part enjoy using it. I just liked vim with tmux more.
Re: the C code, Emacs will happily let you ignore your own config settings. Just turn off anything labeled "electric" and nothing will happen automatically. And don't press tab, that will reindent the current line.
I'm made the transition from Vim to Emacs. I now primarily use Emacs with Evil mode and still use Vim for quick edits with the Vim configuration as a subset of my Emacs configuration. It's the best of both worlds. The Emacs text editing platform is on another level regarding automation, integration and productivity. I have my own config, but I recommend trying the Doom Emacs configuration system if you want to get up and running quickly.
I have read the book and it is the best Emacs book I know of. Highly recommended.
I've been slowly building up a fresh emacs config and feel like I'm getting close to it being able to be my daily driver. I found Mastering Emacs to be a very useful resource though not a perfect fit for me for a couple
of reasons:
1. Like you, I am coming from vim (or using vim bindings in any editor I use). evil-mode is great but the book is focused on vanilla emacs movements and text manipulation and so there's good chunk of the book devoted to that which wasn't applicable to me.
2. This is more of a nit, but I do get a general tone that the book sees having to use elisp as a kind of drawback. Maybe I'm reading too much into that, and it is certainly still the case that you will have to do a lot of configuration to get a setup that works for you. But for me my interest in lisp is part of what makes me interested in emacs so I wish it didn't shy away from it as much.
That said I still found it overall worthwhile for understanding the building blocks and terminology. Also now is a great time to play around with a fresh emacs install. The 29 release has a bunch of goodies that make it easier to build towards and IDE-like experience with many out-of-the box pieces. It comes with a language server (LSP) client, native tree-sitter integration, and a nice declarative package management system that doesn't require any third-party deps (though you can swap the underlying engine to a third-party one if you need the extra features)
I recommend you simply make an alphabetic list of various Emacs commands.
You will see the correspondence between many of the commands depending on the modifier (Ctrl, Alt, Ctrl-Alt, etc.) that is used.
Listing Control then Alt (Meta) we have:
A - Beginning of Line, Beginning of Sentence;
B - Back one Character, Back one Word;
D - Delete Character, Delete Word;
E - End of Line, End of Sentence;
F - Forward one Character, Forward one Word.
and so on.
Most of the letters chosen are mnemonic so they are easy to remember.
Once you have memorised the standard Control and Alt letter combinations, plus a few more such as \, (space), and / and you will find the commands just "fit". They are "in your fingers".
They are also usable on the command-line, bash defaults to using Emacs editing commands as well.
I'm a regular Emacs user. I haven't read the book, but considered buying it once. The ToC and some intro is given in their books page [1]. I didn't buy it because I was already familiar with most of the things in the ToC. The book would be a good intro for beginners and those who want to do things in pure Emacs fashion. However, if you are also a vim user (like me), you're likely to end up using 'evil' package for vim keybindings. Evil is actually very good at emulating vim features inside Emacs.
Emacs is also extensively documented and highly discoverable - even within Emacs. There is a built-in tutorial (like vimtutor). And once you get past a few lessons using their info pages or website, you will have enough skill to pull up the documentation for all core features. The info pages are often books on their own right.
I personally never felt the need for a book. That said, I do recommend buying the book to support the author. Their articles on the masteringemacs website are pleasant and high quality stuff.
It's very well-written and I recommend it, but just be aware that despite the "mastering" in the title it's not meant to be a deep-dive into Emacs. (The author provides a lot of great additional content on his website if you want to go deeper into really mastering emacs.)
One thing I turn to VS Code these days for is Jupyter / Quarto notebooks.
It's not possible to have the same development workflow with Quarto and Org-babel since you can't run/rerun code chunks up to your current cell and automate figure management (for Org-babel).
I think these are not difficult to implement but these days I just want to use something that has these features out of the box and that notebook space is rapidly changing.
Emacs is quite alluring as an idea. I wish we had a "higher" level version of it that could support composing in proper browsers etc. Now I realize this is basically a tiling WM, but I guess I want more interoperability between programs and ability to pass data between them programmatically.
I will take the time to master Emacs when Emacs comes to meet me in the middle, and adopts what has been the industry-standard UI for a third of a century: CUA.
I would love someone to do an Emacs distro which integrated ErgoEmacs into it from the beginning:
https://ergoemacs.github.io/
Because it does not change the program's UI. It just changes a few editing keys.
I used to know one or two dozen totally different editors in the 1980s, some radically different, such as Acorn's two-cursor system, with a source cursor and a target cursor.
There was no standardisation; this was necessary if you wanted to be able to edit text on any random platform you came across. I also worked with one or two dozen totally different operating systems in those days, from Netware to RISC OS to EPOC16 to CP/M to AIX 2 to OS/2 1 to GEOS to TOS/GEM to AmigaOS.
Now, it's different. In the 1990s there was a huge wave of standardisation. Most of those OSes went away and the few that survived adopted standard UIs.
IBM CUA became the industry-standard UI, for DOS, Windows 2/3/95/NT upwards, for Linux with Qt or Gtk based GUIs, for much of Mac OS X, for OS/2 2.x and upwards.
The same base menu layout. The same keystrokes: Ctrl-S saves, Ctrl-O opens, Ctrl-F finds. Yes even on a Mac (but it's Cmd-S, Cmd-O, Cmd-F, but it's very easy to adjust.)
I no longer have to know a dozen editors. I know one UI and it works on every editor from FreeDOS to Windows 11 to macOS to KDE 5.27 to Xfce, LXDE, LXQt, Cinnamon, MATE.
(OK, not GNOME, but that is just one reason among many that I don't use GNOME.)
It is the industry standard and it has been for a third of a century.
Any new editor I might try must conform to it, or I am not wasting my time.
I don't care how much legacy it has. I don't care how powerful it is. I don't care if it will break 40 years of tradition.
It's meant to be infinitely customisable. So customise it. If the user has any existing config file at all, fine, honour it, turn off all the new stuff and start in 1976 mode. No problem. I have no config. I am 100% happy for that to stay for those who know it.
You don't mention any specific part of this so-called industry-standard UI that CUA mode does not provide. I guess if I were really motivated I could try to figure that out on my own, but it seems like a lot of effort because I'd have to play around with both CUA mode and some industry-standard editor (which I'd have to install first).
* The keystrokes to access the commands in that menu tree.
The terminology. I do not have a meta key. You don't have a meta key, either. No new computer since the 1970s has a meta key. I'm a keyboard collector with a deep fondness for clicky mechanical keyboards; in daily use I use a keyboard from 1991. It predates USB and the "Windows" key. It doesn't have a meta key.
for me the appeal of emacs is that it is so very cyberpunk and that it makes me feel like a hacker. seriously. also reducing the tool set appeals to my natural inclination towards minimalism.
I don't see why people are still using 1970s-era IDEs in 2023. Sure, it's a joke that emacs and vim users are at loggerheads, but name me one user of either who isn't a graybeard at this point. And specifically a graybeard who refuses to use more modern tools.
Long after you've migrated from your current favorite IDE twice over, we'll still be using emacs.
Long after whatever company sponsoring development of your current favorite IDE enshitifies them twice over, we'll still be using emacs.
Long after you relearn your IDE workflows twice over, we'll still be using emacs.
And emacs keeps evolving and can handle modern development just fine (except for the most garden-walled ones, and even then...), while not breaking our brains all the time with so many changes and migrations and trend changes.
We want to keep using our tools and get work done, not keep up with the Joneses.
> Yes, if you're talking about a timeframe of ~50 years, use vim and emacs.
There isn't any compromises that make vim or emacs less useful than those tools with much less longevity. They are just as good as an editor to even those who don't care if they will be around 50 years from now.
I used vim (and still using it for non-coding text editing today) but I just don't feel it's so powerful that it's comparable to IDEA. Of course it's probably because I haven't properly taken time to learn and configure it. I only know how to move cursor around, search/replace and enable syntax highlighting.
But that's the point: I don't want to take a significant amount of time to learn and configure an editor. I want a IDE that works well almost out of box.
Maybe my opinion will change if one day I decide to try a more batteries-included vim/emacs like Doom.
I once saw a guy coding Idris in his VIM, having VIM complete everything one could imagine and more. That thing completed whole functions based on signatures and types. And that was all years before the copilot and whatever came up. From then on I believed it, when someone said they could have IDE features in VIM.
I wouldn't have a counter to this normally. I prefer to heavily customize my editor without the support of a starter pack. But yes, starter packs like Doom Emacs and LunarVim do a great favor to these editors by enhancing their adoptibility for new users.
And you can expect during the next 12 years people will be asking why you use such an ancient piece of software, then you'll understand emacs users (if you don't already) :)
Because it's thought out and polished by decades of use.
Because it's extensible.
Your very question, "why are people using an IDE from 1970s in 2023" should provoke some thought. Assuming that these people are not crazy (a lot of them is rather smart and rational), what us so good about Emacs (or Vim) to make it still a preferred choice?
I'm not sure what you mean by graybeard, but I started developing software 5 years ago. Started using emacs 3 years ago (magit). Wrote my own 1000 line emacs config 1 year ago.
I am in my early 20s and started using Emacs when I was 18. The reason I use Emacs instead of a more "modern" tool is because nothing else comes close in terms of ease of extensibility.
I would be interested to hear if you know of any modern editors where extending my editor is as easy as writing one line and running "eval-buffer".
What should I imagine under term "extending"? Is that adding new extensions (like in vscode)? I never felt that this is something I often enough to need quickest possible way to do it.
Or do you mean more like changing how editor looks, how many windows/panes/tabs are displayed and where are they displayed?
So your editor works exactly the way you want it to? Just yesterday I made a tiny tweak to a package that I use (doom-modeline). I haven't thought about it enough to make a pull request, so that tweak now lives on my fork on GitHub. It took me all of five minutes to find out where to make the change, have the code open, and the change made, loaded into my running Emacs session and uploaded to GitHub. And bear in mind I'd never looked at the code for doom-modeline before.
Good tools change the way you work because they make certain workflows possible. If it was that easy for you to tweak your editor, you would too.
Literally changing the editor code, to do whatever you want. Emacs is a lisp (elisp) environment mostly with a small C based core for performance sensitive primitives. But the user code is at the same "level" as the Emacs core code.
This is very different from most extensible editors, where extensions are sandboxed and have a limited, controlled API to the core editor, which is kept separate.
This makes Emacs very "malleable", and it's likely easier than with most other tool to change it in custom, specific ways. It may seem dangerous, but it comes from a culture where this extensibility is very front and center, with documented design pattern to support it (hooks, customization settings...).
Ok, I should have said relatively, or even better "subjectively", small C source base.
The C base supports many platforms and variants, so only a part of it is used in a running Emacs instance. And to the 1+M lines of elisp one typically had many more extension packages. That's the the "relative".
In practice, when I want to change things I don't hit the C layer. Anytime I had to introspect Emacs to change something I was firmly in the lisp world. I don't remember having been limited by something being at the C level, which are things that cannot be changed dynamically. This is really what I meant: in practice to change Emacs the C level (although big in the absolute, and definitely complex) doesn't show up much and hasn't been a limitation at least to me.
I'm not a graybeard, I'm 28 and I've been using Emacs since I was 15. In that time, in my circle, I've seen notepad++, sublime, atom etc. all come and go. Of course everyone at work uses VS Code, in 2 years it will be New Editor by XYZ Corp.
Being old doesn't imply something is bad. Should we be asking what Emacs and Vim have done right so that they're still being used 50 years later?
I think you probably don't know emacs if you think no one should find it useful.
I highly recommend you give it a go. It may not become your main IDE, but I can guarantee that you'll find it very useful for a multitude of tasks, like a lighter text editor, quick REPL, RSS feed reader, binary file reader, org mode (like an organizer of tasks/notes/literal programming etc), magit (the amazing git client), grepping and navigating easily between search result files... and so many other things.
> I don't see why people are still using 1970s-era IDEs in 2023.
Because it works perfectly fine? So your reasoning is because is old is bad. That software that old still is being heavily used today is a testament that these tools have something that definitely the latest craze out there don't. And no, I'm not a greybeard, I'm in my 40's and been using VIM since I don't know when, probably more than 15 years for sure.
I'm not an old greybeard (in my 20s) and I solely use Emacs. What's "modern tools"? Emacs has everything; with the Language Server Protocol it is exactly like VS Code and the like, with autocomplete, find definitions, native tree-sitter support. It can even read PDFs, images, man/info pages, browse the web. I don't see any advantage that VS Code has over Emacs.
Been using Vim for a few months now but I was checking out eww the other day (along with learning more about emacs in general) and it’s certainly interesting…
I have never given emacs a fair shot, so I can't compare the two. Neovim makes it easier to get modern editor features like treesitter and lsp support integrated into the editor. The Lua api seems to have been very well received, so the plugin ecosystem for neovim is thriving. It has also attracted a lot of people outside of the original vim niche (including me!) recently, which means there are more plugin developers who care about how things look and feel to use.
There are certainly some constrains on what plugins can achieve due to nvim being exclusively a TUI, but in my opinion the pros of the editor outweigh the cons.
As to what makes me choose neovim over vscode with a vim plugin, it's a combination of things. One thing I love is that neovim is extremely easy to configure. I also enjoy that everything follows vim rules, rather than some things like file trees or consoles having their own unique rules. I have also become dependent on some vim plugins that don't exist in vscode.
Maybe for whatever work you do your IDE works better for you.
In my case, I mostly code in C++. I've tried JetBrains' IDEs and it drives me insane how slow they are to index and I often get freezes when working on really large codebases.
The same applies to Visual Studio (not vscode).
vscode drives me insane with the amount of dumb notifications it keeps popping up. But I can concede that for most people it works well enough. It also doesn't perform nearly as well as Sublime Text. Working on really large codebases is a PITA with vscode.
If I need autocomplete (which I actually don't like that much), LSP works well for my needs.
The availability of vim in some systems is not reliable. Often only either vi or nano is available. Containers may not have even that (not that it's a good practice to edit files inside containers. It's just for experiments). Emacs meanwhile, has tramp. It lets you edit files remotely and transparently - even inside Kubernetes pods. And you still get to use all your Emacs customization.
You say that, I remember when my team lead was managing a Solaris box and he asked me to take a look as Vim was not working correctly. So I moseyed over and turns out it was Vi instead of Vim. He got confused by c$ not deleting everything to the end of the line.
I would ssh into remote systems, start emacs as my first command, and do everything inside of that emacs window - editing (scripts, config files, code), running shell scripts and programs, reading man pages, executing make, compiling, etc.)
Others would use tramp mode, and open multiple remote sessions within a single emacs. This makes it easy to cut and paste between systems.
If you're not into Emacs, I suggest you give it a whirl. For most development, nothing else will get you close to the joy and productivity that a well configured Emacs can.