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.