I've been a long time emacs user (15 yrs). After vscode was released, I abandoned emacs for most of my tasks. The effort to configure emacs is just too much when vscode does it seamlessly. Would you rather focus on the task at hand or maintaining your editor configuration! Setting up code navigation (jumping to a function and back, seeing all references) for C++ code was significantly complex to setup for emacs (compared to vscode). I choose productivity.
Conversely, I checkout VSCode every few months to see if I can switch, answer is still no. Even though I haven't significantly touched my Emacs config in a few years, the old investments still provide better "out of the box" experience than VSCode can.
Regardless, seeing this submission is about something related to Org-mode, I think your comment is slightly out of place seeing there really is nothing comparable to it across any editors (that I know of).
Well, imo VSCode does require some significant configuration, it's not as usable out of the box.
But the cool thing is that you can override the configuration per workspace and that the config files are just JSON that can be checked into git. Another cool thing is that I can open a workspace in a "devcontainer", which means I don't have to install extensions and so on on the host.
What I really don't like is the terminal from VSCode. It's nothing compared to Alacritty.
> Well, imo VSCode does require some significant configuration, it's not as usable out of the box
Indeed that's what I conclude too. But if I have to configure, tbh I would much rather do it in Emacs lisp than editing JSON. The elisp is a very pleasant and full-fledged programming language that's well integrated and abstracted for configuration. It's also plaintext so can be version controlled like you said.
The "devcontainer" thing does sound like a very nice feature. I am intrigued about how it works though. One can always use volumes/bind mounts to edit source with host Emacs alright, but things like Language Server needs to know location of say 3rd party Python dependencies installed only in the container to provide autocompletion for them. Can VSCode really do completion when language server runs in host, but dependencies are only installed in the container? That would be a nice out of the box feature for sure.
It works by essentially installing a whole "remote VSCode server" in the container and connecting to that. So all of the extensions and everything is installed in the container. Then when you open it up, it just mounts your source code, files and config files into that environment and connects to it.
It is definitely somewhere between architectural overkill and very useful.
People say this, but it seems like a false dichotomy. I use Emacs exactly because I choose productivity!
Emacs might take more time to configure, but that's time measured in hours or, at most, days—a tiny blip compared to the total amount of time you spend programming in the environment! On the other hand, you get a system that you can quickly adapt to your specific needs in a way that other editors do not really support. It's the perfect environment for "situated software"[1], and environment that can grow[2] with your needs and workflow.
Emacs's learning curve and configuration is an O(1) cost for an O(n) benefit. As long as you're planning to use it a lot—and we're programmers, we're going to use it a lot—even a small increase in the benefit is worth a substantially larger up-front cost.
It's funny, I had the opposite experience. VSCode felt like kind of a scattered mess of features that never quite pulled into a cohesive whole. Productivity arguments always made sense for editors like Intellij, where the suggestions border on psychic for Kotlin, but if I'm just wiring a bunch of disparate plugins together I might as well do it with a nice easy config file. Plus Vim has better Vim emulation ;)
Funnily enough the language server protocol makes it a charm for all editors (including nvim and emacs) to use the exact same code intelligence as vscode does. And I find the emacs and vim experience even better since I only have to add the lsp and the respective language plugin to a text file and that's it.
I honestly never had that problem. I did make constant changes to my setup, but that's the way it should be. Ten minutes one week, twenty minutes another, as I continued to eliminate issues. I've come to the realization that some have a problem with spending too much time on Emacs rather than on their work.
These days I use Geany as my primary editor for programming. Something that drives me crazy when I fire up VS Code is that it doesn't have a sidebar helping me to navigate the program (showing function names and such). I'm sure I could get it working that way, but that's not "out of the box" as is so often proclaimed.
> The effort to configure emacs is just too much when vscode does it seamlessly
I've considered that multiple times. It's not that modifying Emacs is difficult (it isn't!) or that modifying VSCode is easier – it isn't, if it's not in a menu or extension somewhere, it's painful just like any other editor except Emacs.
Rather, I've found it was due to:
* Emacs or external tools not playing well with each other
* The Visual Studio Code extensions for popular languages are rather comprehensive and well done. YMMV, sometimes you are lucky to get syntax highlighting. Where Emacs will probably have some pretty battle tested support for more esoteric file formats or languages.
Also Spacemacs was a life saver. I've thrown away thousands of lines of custom Emacs Lisp code.
> Setting up code navigation (jumping to a function and back, seeing all references) for C++ code was significantly complex to setup for emacs (compared to vscode). I choose productivity.
There's a bit of a false dichotomy. When I was a C++ developer, I always edited in Emacs and used other tools (e.g. Visual Studio) for the convenience features. No one insists you have to use one or the other.
Having said that, people who use Emacs primarily for coding are likely not going to stick to it. Emacs is a text editor. Programming is merely one use case amongst many.
That makes sense in some cases, but if you have been an emacs user for 15 years (!) then it is hard to imagine all of your text editiing needs being satisfied moreso by vscode on release. It's a great editor - I use it for webdev mostly, but nothing I have ever used will has come close to org... at least for my brain.
As some who has attempted to use emacs and given up multiple times, I'm actually surprised to hear this. I thought that the difficulty is frontloaded and once you have things set up and some experience with it, it's quite easy to maintain stuff and just keep using it.
It mostly is. I run a pretty minimal config, and it hasn't changed much in a decade. Occasionally I might try a new package to see if it scratches an itch better, but that's about it.
I've been using emacs for 15+ years too. I try vscode and other editors/IDEs periodically but I usually give up pretty quick. The tool that always has me running back to emacs is Magit. I find the git integration of the other editors/IDEs tedious compared to it.
I do a little C# here and there and setting up emacs for productivity in C# was easy: Install omnisharp, csharp-mode, and company. I also happen to like rainbow-delimiters.
But with just those first 3 packages I get "intellisense" in emacs via company-mode. It's awesome.
I switched from Vim to Emacs (specifically, Spacemacs) 1-2 years ago. So much time and effort to configure it and deal with its quirks. (I like Emacs and plan to stick with it longer, but I still think it has a number of issues).
