I hope my question makes sense.
I am using Doom Emacs for a while now and have become fairly proficient. But I feel like whenever I am browsing emacs content online there are still many topics for me to discover. So I was wondering if there is anything that I might be “missing” yet which might help with my productivity or improve my development skills.
Sofar I what have learned, on top from my head:
- Org/Org Agenda (refile etc.)
- Magit
- Vterm
- LSP Commands
- Multiple Cursors
- Literal Config
- Navigating Emacs itself (which key, debugging, reading Emacs-Lisp (abit))
- Using Language specific commands, i.e. send buffer to repl
- Using Undo with Vundo
Only thing I know that I still need to learn is beeing more proficient with vim keybindings, but with that I know where to start.
I know the question is quite broad, but maybe there some “killer features” worth to explore which I am not aware of yet.
I’d appreciate any input.
I feel like whenever I am browsing emacs content online there are still many topics for me to discover.
This will never not be the case.
My suggestions are:
- focus on addressing known pain points
- if something seems very popular, it might be worth trying to learn why and whether it could be beneficial to you as well
- if something else sounds super-interesting, take a look
- don’t fret about not keeping abreast of everything – it’s almost certainly impractical
The thing that made everything click into place for me: buy the “Mastering Emacs” book. Read it, read it again… And again…
I still re-read it all the time and always pick up something new. I don’t know to what extent using something like Doom will interfere with things, but the book is still and easy recommendation.
How can I become a more “proficient” Emacs user?
Just use it. It is that simple.
I also suggest being patient and looking up the documentation and the built-in help whenever you have a problem.
Don’t fall into some of the common pitfalls I see people here do often:
Don’t insist on super customized Emacs according to your liking from the early beginning. Be patient, and do stuff Emacs way, or live with some more irritated moments, and leave minutiae customization for later, when you are more familiar with Emacs. Emas is to be customized by each and every one and bent to your needs and personality, but it may take some deeper knowledge of Emacs in some areas, so to save yourself some frustration and lots of time, proceed gently at customizing Emacs in the beginning. This will probably be a somewhat controversial tip for some people, but what I mean is, prefer to do the work you have to be done, over how you do it in Emacs. In the beginning, bend yourself around Emacs, and keep in mind, that the more you are used to Emacs, it will be easier and faster to bend Emacs around you.
Yes, there are many tips and stuff accumulated on the Internet, but you can not learn everything at once. With the amount of information available, it is probably better to concentrate on using Emacs to do your work, and focus on exploring only those topics that give you the most in terms of how you perform your work; for example to solve some very irritating thing or to automate something, etc. You don’t have to start using Emacs for everything immediately, let it come with the time as you are getting more and more used to Emacs. What might be a killer feature for someone, might not be a killer feature for yourself.
Being popular does not always mean very good. Popularity goes in waves. You can spend all your time just re-learning “popular” frameworks and things. Instead of focusing on which package you should use for this or that; choose one and just use it. Once you find some true shortcoming that irritates you, than look for another package or for tips on how to change it, etc. If you are using Doom, I am quite sure they have already included something that is good for most people. I personally just use whatever is default in Emacs and have had no issues with it; for like 25 years now, or something there and counting.
I think this is really great advice.
Try to identify the biggest inefficiencies/annoyances that you encounter in your real daily work, and use those things as motivation for learning about a specific part of Emacs. Every time you fix some small problem with your workflow, you will become a little more knowledgeable and efficient, and over time you will become a master.
As a simple example, a beginner Emacs user might notice that they’re spending a lot of time navigating to the same files/directories over and over with M-x
find-file. And that might motivate them to learn about packages for opening recently visited files (e.g.recentf), or to learn about Emacs’ bookmark system. That’s a really basic example, but I think that repeating that general “improvement loop” over and over is how people become good at Emacs.I want to note here that there is a eternal temptation towards “yak shaving” with Emacs, where you spend all your time working on your configuration instead of getting your actual work done, whether that be school assignments or tasks for your employer. Personally, I have a rather extreme rule that I don’t make any adjustments to my Emacs config during working hours, unless I can make the change in less than 5 minutes. Instead, I keep a TODO list of possible improvements and do those on my own time.
Finally, I second the advice given elsewhere in this thread, about starting with a vanilla Emacs config. Emacs distros like Doom/Spacemacs/Prelude are great for showing you what’s possible, but you will understand your config so much better if you build it up from scratch. That will also help with gradually learning how to program in Elisp, which is a total game changer and probably the single most valuable thing you can learn.
While minimal/vanilla Emacs configs aren’t as flashy Doom/Spacemacs/Prelude, they can be really effective. For example, Twitch coder @tsoding uses a very vanilla Emacs config, but he does things at a dizzying speed. For example, see the following video where he is doing some coding experiments with the “tree sitter” library: https://youtu.be/-8p-Jd9n-_I?t=549
I think this is really great advice.
Try to identify the biggest inefficiencies/annoyances that you encounter in your real daily work, and use those things as motivation for learning about a specific part of Emacs. Every time you fix some small problem with your workflow, you will become a little more knowledgeable and efficient, and over time you will become a master.
As a simple example, a beginner Emacs user might notice that they’re spending a lot of time navigating to the same files/directories over and over with M-x
find-file. And that might motivate them to learn about packages for opening recently visited files (e.g.recentf), or to learn about Emacs’ bookmark system. That’s a really basic example, but I think that repeating that general “improvement loop” over and over is how people become good at Emacs.I want to note here that there is a eternal temptation towards “yak shaving” with Emacs, where you spend all your time working on your configuration instead of getting your actual work done, whether that be school assignments or tasks for your employer. Personally, I have a rather extreme rule that I don’t make any adjustments to my Emacs config during working hours, unless I can make the change in less than 5 minutes. Instead, I keep a TODO list of possible improvements and do those on my own time.
Finally, I second the advice given elsewhere in this thread, about starting with a vanilla Emacs config. Emacs distros like Doom/Spacemacs/Prelude are great for showing you what’s possible, but you will understand your config so much better if you build it up from scratch. That will also help with gradually learning how to program in Elisp, which is a total game changer and probably the single most valuable thing you can learn.
While minimal/vanilla Emacs configs aren’t as flashy Doom/Spacemacs/Prelude, they can be really effective. For example, Twitch coder @tsoding uses a very vanilla Emacs config, but he does things at a dizzying speed. For example, see the following video where he is doing some coding experiments with the “tree sitter” library: https://youtu.be/-8p-Jd9n-_I?t=549
Window manager Exwm maybe?
combine these😎 use multiple cursors in an editable ripgrep result buffer. or in an editable dired buffer. use project.el or projectile, use radio buttons in org or define your own buttons in hyperbole.
Just Use Vim
Learn lisp :)
I’d suggest not to attempt to become proficient at Emacs for the sake of it, instead.
- Use Emacs for whatever you need an editor for.
- Ensure your workflow is good.
- If you see some room for improvement, investigate packages/configuration.
- If you need to scratch an itch, write your own commands/packages.
Once in a while you might like to play & explore areas you didn’t dig into before but you don’t have to. Have a nice workflow, get your work done - and leave it at that :)
For some context, packages I’ve developed: https://codeberg.org/ideasman42
This is the way, adress pain points, don’t do things for the sake of it.
You will naturally dig deeper in the things that matter to you
If you hear of some fancy new package, read/watch an introduction about it and ask yourself if it would actually solve one of your issues. If it doesn’t really, pass
I completely agree with this summary. Find something in your existing workflow that could do with improvement, and seek out a solution. For example: you want to jump quickly between windows, look up Ace Window; or, you want to jump quickly across the text visible on the screen, look up Avy; or, you want to jump quickly between files and text in your repository, look up Counsel.
Invest in a few well made frameworks, but only one at a time, and allow yourself to internalize their concepts and key bindings. It is helpful to write out the keybindings that you intend to memorize. A framework or package will often have dozens, but you will probably only ever commit to a handful. Review the list after a month or two, and you will likely find the ones that stick with you.
I have used Emacs exclusively since the early nineties, so I’ve seen whole frameworks come and go. I’ve also wasted a lot of time on some of them, e.g., Org Mode is something I swore off almost a decade ago. What I appreciate most about Emacs is that learning it has truly been an investment, since it has had incredible staying power and there’s enough in the vanilla install that I can install the package on a new Linux box and immediately be productively editing files
e.g., Org Mode is something I swore off almost a decade ago.
I’m curious (not arguing) why you swore off Org-Mode? This is why I came to emacs from more of a vim background and keeping notes in markdown.
I found Org-Mode impossibly big. It offers so many different concepts and has so many mechanisms for configuration and extension that I spent years and hundreds of yak-shaving hours configuring it, but I found it completely unreliable.
There are some highlights. The date editor is incredible and impossible to fully replace. The list editing functions and bindings are also incredible, but easier to replace and less truly useful since they encourage a sort of endless mucking with the structure of lists.
The tree structure for notes sounds brilliant, but in practice does not scale well. I thrashed around for several years between trees of different sizes: a single tree, a tree per focus area, a tree per project. Each approach brought unsolvable pain points at large scale in the details of searching, archiving, tagging, viewing, and reporting. I spent a long time thinking it was something additional that I needed to do or configure, and would burn hours getting it just right, but each solution would either get bit rot or be too reliant on the particular tree structure, so be lost when I reorganised.
I gave up and retreated to a 3 level directory structure of active/archived, area of focus, project. I instituted a naming convention for project folders. I let projects be small. I found ways to query the directories using
counsel-gitandcounsel-ag, namely search over filenames and the silver searcher or find and grep.
I completely agree with this summary. Find something in your existing workflow that could do with improvement, and seek out a solution. For example: you want to jump quickly between windows, look up Ace Window; or, you want to jump quickly across the text visible on the screen, look up Avy; or, you want to jump quickly between files and text in your repository, look up Counsel.
Invest in a few well made frameworks, but only one at a time, and allow yourself to internalize their concepts and key bindings. It is helpful to write out the keybindings that you intend to memorize. A framework or package will often have dozens, but you will probably only ever commit to a handful. Review the list after a month or two, and you will likely find the ones that stick with you.
I have used Emacs exclusively since the early nineties, so I’ve seen whole frameworks come and go. I’ve also wasted a lot of time on some of them, e.g., Org Mode is something I swore off almost a decade ago. What I appreciate most about Emacs is that learning it has truly been an investment, since it has had incredible staying power and there’s enough in the vanilla install that I can install the package on a new Linux box and immediately be productively editing files
There’s so many things you can learn from! Since you mention wanting to improve how you use Emacs for development, a couple of features that I use everyday and feel very “emacs-y:”
- compilation-mode (`M-x compile`) - It defaults to a `make` but the resulting buffer is useful for any sort of build/compile/test job that you want to spawn. For example, I’ll use Projectile’s `projectile-test-project` command (`C-c p P`) to quickly run jest tests for my TS projects:
https://i.redd.it/xyte0s83if3c1.gif
- occur - (`M-x occur`) I use this mostly as a persistent search buffer. Basically, you can list lines that match a search string and then follow and/or visit them in the corresponding buffer. I like that the numbers in the occur buffer give you a rough idea of where the search term is in the original buffer. Pressing `n`/`p` in the occur buffer advances to the next line as well as gives a quick highlight in the original buffer.
The killer feature is emacs lisp. Once you’ve gotten a handle on the general, day to day use of emacs and the packages in your quiver the next step is to learn the language that powers the system. This will open up an incredible amount of power and customizability. It will change what you think emacs is, fundamentally.
Writing your own functions, modes, and packages is the thing that makes emacs emacs. Right now, you configure your system. But once you learn emacs lisp you will be able to customize it. This is a huge difference.
I recently made the switch from Doom Emacs to Vanilla Emacs because I wanted to get a better understanding of the nuts and bolts of emacs-configuration which meant getting more into elisp and becoming more familiar with how to customize things from scratch in that language.
Doom was great but I also found it abstracted away some of the help I found online which was directed mostly at vanilla emacs users with use-package and such. I was in no way qualified, to try to understand how doom built up from vanilla emacs to provide, for example, its package management abstractions.
I chose Doom initially as I was a long time vim user who know h, j, k, l and other movement commands on muscle memory. If you aren’t already familiar with vim keybindings you can try a game like this https://vim-adventures.com/. I do prefer vim keys to emac defaults since holding down modifier keys to do commands have caused issues with my hands. I also use an emacs package called god-mode and evil-god-state (evil = vim capability in emacs) to reduce having to hold down modifier keys for commands.
The took the move from Doom to Vanilla emacs slowly and I set things up so I could run both my Doom and Vanilla at the same time. I didn’t want to lose productivity until I could get my Vanilla emacs config up to speed. I don’t know what OS you use but I simply asked ChatGPT about running two different configs at the same time for my OS and it walked me through. You will maintain your ~/.doom.d directory for that config and then you can start another directory like ~/.config/emacs with an init.el file for that. I’ve found ChatGPT very helpful for emacs in general though it does get a lot wrong too but not enough not to use it.
I’m going through the System Crafters “Emacs from Scratch” playlist slowly. You can find that playlist here https://www.youtube.com/@SystemCrafters/playlists . There is a playlist on “Learning Emacs Lisp” too but I haven’t made it to that one yet.
Finally I recommend literate programming setup for your config. The “Emacs from Scratch” playlist from video 7 shows that. Thus my init.el is generated from an init.org via org-babel-tangle. The advantage of putting your config in org source blocks like this is you can create a hierarchy within org and put in all the extra notes and links you want to explain the why and how of your configuration without cluttering up the actual init.el with a bunch of comments. It’s easier to read and navigate, at least for someone with little elisp experience like myself. This is a fairly popular example of emacs configuration via literate programming https://pages.sachachua.com/.emacs.d/Sacha.html.
I also recommend putting your config files under git version control so you can easily get back to configs that “worked” as it can be easy to make breaking changes and you will want to revert to an older copy.
Use “C-h k” and then press keys to find out what Doom emacs is using. You will begin to see packages like consult, counsel as part of things you will want to install in a Vanilla package as the worst thing about Vanilla that Doom will spoil you on is autocompletion lists.
rome wasn’t built in a day and neither will be your knowledge of emacs, just use it, repair stuff as you need to, change stuff when you need to, just that
Honestly if you want a better understanding of the software you could always try switching to vanilla and writing your own config. Also if you aren’t too familiar with vim keybinds why not try Emacs keybinds, they’re honestly quite good and work well. I swear by them
I just replace evil-insert-state with the normal emacs keymap; best of both worlds!
Meow.el is a great package for those who want Modal editing without having to change everything in your config to fit Evil “way of doing things”
I memorize flash cards of all the elisp functions and M-x commands.
And make them in Emacs!
let’s revamp emacs early manual
You have to be trolling right lol
Things I’d recommend checking out:
- start using dired as a file manager.
- get comfortable with macros.
- hyperbole as a bookmark manager on steroids (specifically explicit buttons).
- find a templating system for standard document/code generation (I use yasnippet after failing to make sense of srecode).
- write an interactive emacs lisp function to solve a text editing problem; extra credit for clever use of temporary buffers.
