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).
org-roam is a solution for effortless non-hierarchical note-taking with org-mode. Basically, if you already using org-mode - it's a personal wiki-like system for your files.
It's funny that I've been using Emacs on windows 10 for years, and I would say that my work flow has only about 5% in common with the stuff in this repo.
Author here. Would love to know what’s the common 5% and the major differences.This guide was written with a complete beginner with no programming background in mind (myself 5-6 years before includes). I think veterans’ wisdom and experience can help rookies a lot.
Do any friendly folks here have advice about shell choices in emacs on Windows 10? Using MSYS typically works well enough for me for simple commands, but I always have a separate Powershell window open for more detailed work and actually running my compiled binaries. Generally I have found the shell in emacs on Windows to be very finicky and difficult to use.
It has always been a minor pain point and I’ve had trouble finding reliable info. Ideally we could just use Powershell but I understand this is quite tricky. Powershell.el[1] didn’t actually work for me (beyond the editing mode) when I last tried it but I do see there’s a somewhat recent update.
WSL1 using a minimal rootfs from any debian distribution (so you can apt install things you need), accessed with wsltty as Windows Terminal has many issues (but supports tabs if you can live with it). This gives the best results overall: compatibility (amd64 instead of mingw), flexibility (apt install) speed (powershell 1) especially if you mount and access a CHD for your own files instead of using the regular tree inside NTFS.
Also, if you really like powershell, use the linux version next to bash
As someone who is an avid emacs user and had to switch to windows with my last job change, this is super helpful. I’ve already got my own org-mode note-taking process, but I struggled quite a bit with other quality of life features on windows. This article is a great resource on getting spelling, docx exporting, and other quality of life configurations.
It’s good that your tutorial has people start with menus and doesn’t mention moving point using whatever non-arrow key chords do it (never bothered to learn. Fortunately I’ve been able to avoid teletypes and serial terminals in my computing journey.)
The ‘traditional’ Emacs tutorial methodology is like teaching people to type with the first step being: change your keyboard layout to Dvorak. It’s ridiculous.
I appreciate that you speak to your target audience in their language, rather than the language of the Emacs religion. (It makes me think of English vs. Latin.)
I store .emacs and other dotfiles in Dropbox, I’ve seen other people have been happy with Github as well. This way you get synchronization across all devices and backup; and your entire configuration process is pointing to the location of the file.
It's extremely unlikely that Emacs would be at fault. Doom, perhaps.
And as everyone else has said, you definitely want to back up and version control your Emacs config. Most of the power in Emacs come from customizing it to your needs, and without it you'll lose much of your workflow.
I prefer the windows version. It respects all the native graphic elements of windows like font hinting, high dpi and and transparency better and I can drag and drop from explorer into it. It's also nice that I don't need to start WSL and an xserver to get it going.
