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’d suggest not to attempt to become proficient at Emacs for the sake of it, instead.
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
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
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-git
andcounsel-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
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