In VS Code I use "Awesome Emacs Keymap" extension by Yuichiro Tachibana (Tsuchiya):

https://marketplace.visualstudio.com/items?itemName=tuttieee...

What won me over? GH Copilot + the overall packaging. It just works. Good UX.

A quick google search got me vscode-dired (incase anyone else runs into it):

https://marketplace.visualstudio.com/items?itemName=rrudi.vs...

Quick Tip: I set C-x C-d, C-x C-b and C-xb all to call extension.dired.open per this stackoverflow: https://stackoverflow.com/questions/62235792/how-to-add-mult...

that seems to satisfy the muscle memory... and it seems at first glance that this time the switch to vscode might actually stick. (thanks for the link to the emacs keymap extension)

We'll see how it goes!

edit: After even 5 minutes of building some rust code I ran into too many issues! I love the syntax highlighting in VS Code and everything else but I have way too much custom elisp to build and debug Rust/Go/C++ and recreating all that in VSCode or learning the new bindings is a bridge too far! I would pay real money to someone who would build an amazing performant experience for emacs. Sigh.

* except RustRover but that comes with its own set of issues

What kind of emacs scripts do you write to help debug Rust?

Then I have a bunch of elisp code that calls just and / or generates boilerplate code right in the buffer - M-x new-macro or M-x run-test (asks for a test to run) etc. I keep writing more elisp as I go along and add specific key bindings to specific things and now its too hard to move away from it all.

Have you tried https://github.com/blahgeek/emacs-lsp-booster? Also, build Emacs --with-native-comp flag

That "it just works" thing gets me all the time. I just don't get it. Some things surely do work nicely out of the box in a proprietary specialized tool, like for example JS/TS-related things indeed are very nice in VSCode. Just like Java-related stuff works great in IntelliJ.

But programming is far more than writing code. I can argue that writing in plain English for a programmer is perhaps far more important than writing in a PL.

And for any kind of plain-text manipulation, Emacs absolutely has no match today. Of that, I'm certain, because I have watched and followed many VSCode/IntelliJ power users and long-time users, and I do occasionally use those tools personally as well. There are so many practical example use cases where Emacs just kicks things out of the ballpark - from sending requests to LLMs in the midst of taking notes, to controlling video playback, and annotating PDFs - typing those annotations while browsing the document.

And then that "it just works" fallacy. No cookie-cutter solution ever can make a true coder happy. How can one not get annoyed by a bunch of minor, seemingly not-big-of-a-deal issues over a long period of time? Like having to use the mouse for certain operations without a good alternative, or fixed keybindings that can't be fully customized, or the search bar not remembering your last search position and parameters? It's like buying a car with seats at a fixed angle and not even being able to change that.

I mean, sure, Emacs may seem dauntingly complex at first glance, but the initial investment in learning this infinitely hackable tool pales in comparison to the countless hours lost wrestling with the unchangeable constraints of less adaptable alternatives.

> I tolerated the LISP aspect.

I don't know the extent of what you meant by that, but I guess you've "acquired a vehicle," using it to commute and go grocery shopping, and never even realized that you had an actual spaceship all this time. Emacs is most importantly "a Lisp Machine" with a built-in text editor and not the other way around. It is exactly Lisp that makes it so fascinatingly hackable. One chooses Emacs, Lem, Light Table, etc., specifically because of Lisp, not to "tolerate" or "suffer" through dealing with it.

Still use emacs + org mode for notes though, and spent quite a lot of time getting VSC to act like emacs in terms of shortcuts etc.

Sounds like you didn't switch, but rather added another tool in your toolbox.

The constant comparisons to VSCode frustrate me because they're often presented as "either-or".

I use Emacs. And I use VSCode.

I can say the same for Vim... My primary editor is Emacs, but I use vim if I want to edit something quickly in the terminal (config files, git commits, etc). If the codebase is bigger then I use the JetBrains IDEs...

I installed VSCode but I just don't like it. Until today I didn't find a use case for it being added to toolbelt. But I must admit that it almost won the editor wars, people just suppose that you use it.

I switched in late 2015, things were different back then. If it was today I think I would probably jump to Doom Emacs or Neovim.

What?

> the plugins are ass > the LSPs are horrible for basically anything which isn’t Typescript

What??

I need to edit projects on a remote machine nearly every day. (I do cross-platform Python dev so I need to run and test code on Windows and Linux VMs while working on a Mac.) Compare VSC’s Remote Edit plugin to TRAMP and let me know what you think. For me it’s not even a contest. TRAMP just simply doesn’t work in a majority of use cases and I’ve only had a few small hiccups with the VSC Remote Edit. Getting LSP plugins working over TRAMP on another machine is hell. I just use Emacs for org-mode and Magit now.

[Yeah, yeah, I know, I shouldn't be running NixOS and I should use a Microsoft (c) approved OS instead like all the cool kids. Wake me up in 100 years when Microsoft ceases to exist.]

Also, the emacs approach uses very little resources. This matters if your LSP server takes 80% of your RAM. Vscode takes 20%, emacs/tramp doesn't.

You would have to compare what VSCode does to running Emacs server side and connecting with Emacs client to the server. Then it would be a fair comparison.

Maybe you don't have to use VS Code full-time, but having a knowledge of it is useful.

Personally, I started using VS Code because support for frontend is much better there than in JetBrains IDEs and it has great remote editing capabilities. I would prefer to use JetBrains IDEs (I did for many years, and I still go back for Java), but VS Code is just better. I would never use Vim for editing full-time, though I do use lunarvim when I need to quickly edit a remote file.

I am not sure how the speed of both compares, if one properly sets up Emacs on the server as well, to make it a fair comparison.

It depends on so many different things. Aside from platform specifics (sure, it can be painfully slow on Windows), Emacs might feel slow for various reasons, but it doesn't have to be. Built-in Profiling tools are godsend and if used properly Emacs can be quite impressively fast. My Emacs starts quickly (in less than a second), and it is very pleasantly snappy.