Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I started using GNU Emacs in the mid 1990s. I like the ergonomics of the interface. It's muscle memory since long. I tolerated the LISP aspect.

In VS Code I use the "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, polished UX. Emacs needs to catch up on this front.



I've been using emacs for 30 years and have tried VS code several times but the muscle memory on Emacs has prevented me for switching. I've gotten LSP on emacs working well enough but the performance just isn't there. So today thanks to your suggestion I tried it once more with the Awesome Emacs Keymap extension and right away I ran into not having dired mode to switch files.

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.


Depending on the language you use VScode might not be any more performant because it probably uses the same LSP on top of electron instead of elisp. I write Rust/C++ on a sizable project and since everyone depends on rust-analyzer* all IDEs are just unbearably slow and mostly useless in language integration beyond basic refactors and click to go to definition.

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


yes its rust. Looks like you're right. Well is back to good old emacs for me!


> I have way too much custom elisp to build and debug Rust/Go/C++

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


Nothing special or too sophisticated. On the one hand I use Just (a command runner) to standardize specific build and test commands that call cargo with various flags. Here is a simple example from one of my repos: https://github.com/deepmesa/deepmesa-rs/blob/mainline/justfi...

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.


> LSP on emacs working well enough but the performance just isn't there.

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


Copilot is available on Emacs, but yes, a lot less polished.


> It just works.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: