I’ve rebuilt my emacs config a few times for exactly this reason!
Some of the things I’ve found work well for me:
- it’s pretty obvious, but it took me a while to figure it out: make your `~/.emacs.d` into a git (jj, hg, whatever) repo. You don’t need a remote but as you try things out it’s nice to be able to step back in time.
- know what you want to build. For me I’m generally trying to make emacs do something that I’ve seen a colleague’s editor do: integrating language servers for source navigation; integrating a debug server for a nice visual debugging experience.
- some people manage their emacs configuration as org-mode files. This is neat because you get an experience similar to Jupiter notebooks: you can intermix commentary and elisp. I haven’t ever gotten to this point but it looks neat when I see others do it.
There are some good YouTube channels and blogs that talk about configuration, or that test different packages. I’ve found “Emacs from Scratch” and “Emacs Rocks” to be really useful.
There’s a lot to customize and select from. Without steering you one way or another, here are some changes I’ve made recently or packages that I use:
1. For language servers, I find `lsp-mode` to be easier and more full-featured than `elgot`.
2. `dap-mode` plays nicely with `lsp-mode` and makes debugging straightforward.
3. I’ve tried, and use, a few different plugins for AI coding: `greger.el` is the first one I tried, but I’ve started using `xenodium/agent-shell` more. If you want to write (or hack on) an AI agent written in elisp, there’s `steveyegge/efrit`.
4. You’re probably accustomed to some sort of “tab completion” from neovim. Within emacs you’ll need to set up a “completion framework”; there’s a bunch to choose from. Watch some videos and experiment. You’ll probably find one that feels a lot like you’re used to (whether that’s completion-as-arrow-navigable-dropdown-at-cursor, or completion-in-side-panel, or whatever).
Your muscle memory of how to move around in a document and how to tell your editor “I want to do something new now (see a list of open files, go to a new file, etc)” isn’t going to translate into emacs very well. It’s like shifting from a laptop keyboard to some weird split keyboard with thumb paddles: muscle memory won’t be satisfied, and you might just “not like” emacs due to that. There’s `evil.el` (“Emacs VI Layer”) which teaches emacs to recognize vim-style commands. I think vims have fantastic macro recording and replaying functionality - emacs has it as well, but making a recursive macro is harder for me, for some reason - and evil makes emacs’s macros feel on par with the vims.
Another tripping hazard coming from a vim-like is that “undo” operates differently in emacs. I think the vims have a fairly linear undo: like a browser history back button. emacs stores an undo tree, which can lead to surprising behavior at first.
If you’ve written or tweaked plugins for your editor and enjoy tinkering with your tools, then a vanilla greenfield approach to emacs will probably be very satisfying for you.
If you want something that “just works” which you can experiment with and gradually learn more about over time, then you might get more mileage out of spacemacs.
I think vim-style users tend to launch vim many many times through the day. cd here, edit a file; save, quit, edit the next file. emacs can act like an editor, but if you think of it as a highly customizable IDE, then you’ll get more use out of it. My uptime on emacs is generally measured in months, whereas for me vim is in seconds to minutes. I mention this because the startup time for emacs can be quite slow compared to vim; just don’t pay that cost over and over.