belden
last Saturday at 6:29 PM
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.