5 ms·
Every so often I would start my Emacs config over from scratch. I might port over some old defuns from the previous, eventually, but I would always endeavour to
by dleslie 5y ago
Every so often I would start my Emacs config over from scratch. I might port over some old defuns from the previous, eventually, but I would always endeavour to try the latest tools and best language configurations. Consistently I found myself using Emacs and sticking to it because it offered the best developer experience.
And then came Microsoft's Language Server Protocol. Emacs was late to adopt it, and still has generally spotty support for it. This has caused me to stop using it, almost altogether, as Emacs is objectively inferior because of its poor support for LSP.
Its largest competitor, VSCode, Just Works most of the time! You load a file, it detects your intent, and it will install the necessary extensions _along with any additional system packages necessary_. Compare this to Emacs, where it's usually quite unclear what packages to use and what tools they need to operate. Eglot? lsp-mode? Which language major mode, and which language server? How do I get them to work with company mode and so forth?
And then when they do work, the packages often drift and break. I had C# working quite well with lsp-mode and OmniSharp, and then I updated Emacs. Without any changes to my configuration the experience has become atrociously slow, and apparently this is due to a known and recently introduced bug in Emacs support for C-style modes.
I strongly recommend other Emacs users shake the sunk cost fallacy and just try the competitors.
- BeetleB 5y agoThis makes sense primarily if you assume people who stick to Emacs do so because of its SW development capabilities. As a person who hangs out amongst Emacs communities, this profile is not the norm.
- dleslie 5y agoI used Emacs for software development and git interfacing. I tried organizing my knowledge with org-roam. I tried maintaining org todo lists. I tried having an active org-agenda. I tried... But what I do more than eight hours a day, every week day, is read, write and debug code. Emacs was once the best, it is now not so great. I've been using Emacs for over two decades, now. It's painful that it fell behind so quickly.
- maximus-decimus 5y agoI tried org-roam too and it just feels like a bad joke compared to VSCode's foam. Foam has a real time graph of your notes. In org-roam, you need to call a method to get a static graph open in your browser. In theory, you can click the nodes in the org-roam graph to go to your notes... but it doesn't work out of the box for me. Whereas in Foam I can just ctrl+click on a node and bam, i'm in the file I want to be. I also really like that Foam lets me edit files in markdown in the left window while seeing the rendered version in the right window. The trade-off is this seems to waste screen real estate like there's no tomorrow, but with a 4k screen, I think it's worth the trade-off.
- kazoomonger 5y agoI actually just started using emacs recently, specifically doom emacs. It works smoothly out of the box and is super easy to enable LSP for. I'm not going to try to convince anybody to switch, but if you ever try emacs again, would definitely recommend trying out doom emacs.
- forty 5y agoSame. I actually switched from VSCode, and I like it much better :)
- YetAnotherNick 5y agoI switched from Emacs to VSCode to doom emacs and will not be going back anytime soon. For people who mainly want to focus on development, I would say it is fine to break the conventional vim/emacs wisdom that you should start from scratch.
- nine_k 5y agoIf only VSCode had sane buffer control, and the idea of buffers. I use VSCode with Emacs key bindings for certain development. The lack of uniformity inconveniences me a lot. But indeed, VSCode is the closest thing to Emacs in its spirit.
- Koshkin 5y agoJavaScript: "Lisp in C's clothing" https://www.crockford.com/javascript/javascript.html https://www.crockford.com/javascript/javascript.html
- iLemming 5y agoNo, it's not. It's nothing like Lisp and will never be, simply because it misses the biggest (arguably most important) feature of Lisp - homoiconicity. But sure, if you squint your eyes - pretty much every single modern programming language would be "like a Lisp" Why? Because there's not a single programming language in use today that was not influenced by ideas first pioneered in Lisp.
- krylon 5y agoI haven't given them a close look, but there is a project called "zile" that - AFAIU - aims to create an emacs-like editor using Lua instead of Lisp. Which sounds amazing to me. Also, there's another project to replace emacs' lisp interpreter / bytecode VM with GNU Guile, which started out as an embeddable Scheme interpreter, but apparently these days it is a JIT compiler that supports Scheme, Javascript, and elisp. Which means Guile-Emacs could absorb all of that elisp code without a problem, probably make it run faster, too, but also open the door for people that don't feel comfortable with elisp. More importantly, maybe, this project could bring people from different language communities together. Again, I have not spent much time looking into the project, so consider all of what I'm writing hearsay. But things are happening.
- PaulDavisThe1st 5y ago> Its largest competitor, VSCode, Just Works most of the time! You load a file, it detects your intent, and it will install the necessary extensions _along with any additional system packages necessary_. Compare this to Emacs, where it's usually quite unclear what packages to use and what tools they need to operate. Eglot? lsp-mode? Which language major mode, and which language server? How do I get them to work with company mode and so forth? If you actually think that what VSCode can do here is remotely equivalent to what Emacs can do after customization, then I suspect you don't really understand Emacs. Yes, VSCode does an excellent job getting you to 80%-90% of where you want to be. But because of the lack of a deep extension language (or to be fair to Emacs, an extensible implementation language), VSCode will make it very hard to get to precisely where you want to be. Maybe that's OK for a lot of people. But those of us who have used Emacs for quite some time are quite attached to that "final 10-20%", and you can keep your language servers and "detecting my intent" and just leave us be with the way we do things.
- dleslie 5y agoFor that last 10% of esoteric power, _I still launch Emacs_. Eventually VSCode will be able to do such things, too.
- saulrh 5y agoIt's not even that - My problem is that I depend on emacs for the first 50% of my workflow, not the last 50%. For example, I use key chords for every common operation - ;h ;j k; l; move between panes, xz invokes M-x, kj brings up the buffer list, z\ and z- split panes, etc. I barely go ten seconds without using one of occur, change-inner, a 500-element kill ring, consult-yank-pop, tramp, magit, etc. Emacs works so well for me not because it has crazy extensions, but because its extensibility goes so deep that you can bring the crazy extensions deep into the tightest loops in your interaction with the editor where you can gain the greatest benefits.
- axiosgunnar 5y agoVSCode allows you to write in Javascript what Emacs allows you to write in elisp. What's missing?