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.
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.
I don’t get the concept of learning vterm, you just start it and use it with Emacs key bindings. Just stop using garbage like Doom Emacs and evil, and start making your own set up.
-
emacs-pinky impacts some users such as this https://www.reddit.com/r/emacs/comments/44c0ed/emacs_pinky/ . I’ve got Caps Lock mapped to both Control (down-holding) and Escape (up/down). Maybe not you at this point in your life at current usage level. And you could just be lucky and never have physical issues at all with hands and fingers and wrist.
-
vi can be found on almost any linux box so knowing the basic commands to work with text files when you might not have the luxury of installing is useful - ubiquity argument
-
the text-objects, somewhat more advanced to learn, in vim are not replicated by default in emacs and you will miss them in editing if you have put them in muscle memory. So things like da( or di( or ci" or ya{ and so on where d is the command and a( or c" and a{ are examples of a much larger list of objects that are easily manipulated
In any case things become a matter of preference and are subjective unless one remains a purist in the spirit of the church of emacs vs vim. The OPs biggest challenge is he appears to be trying to learn vim at the same time he is starting emacs. Many who came to Doom or Spacemacs were vim users switching to emacs.
-
What even is vterm? I’ve never heard of this tool before.
And I agree, if your gonna use Emacs regularly your most likely gonna want to start customising it to your liking. Though configs like Doom and Space are decent for beginners, eventually they are just gonna get in the way of progress.
I think they’re also harmful, OP is feeling he has to learn vim bindings due to Doom Emacs. I agree they are good for users who are heavily wounded people by vim’s modal editing and shortcuts, but they need a real treatment eventually.
I think calling something like Doom as garbage is unwarranted and objectively untrue. It is a huge community project that is addressing the needs of that community and has helped a lot of people (myself included). Simply Because the needs of that community are not the same as your needs does not mean it is garbage. Even for people not using Doom, it is a hugely valuable resource for different ways to configure packages. I no longer use Doom, but I and others frequently return to their source to learn some tips on how to configure different packages.
People should simply use the right tool for the job. If someone wants to hit the ground running with sane modern defaults, doesn’t want to spend a lot of time configuring Emacs, and wants to use Vim bindings, Doom is an excellent choice. If someone wants to learn how to configure Emacs on a deeper level, spinning your own config is maybe the way to go. Neither is right or wrong, they are simply serving two different purposes, and that is fantastic!
Elisp manual. Helpful. Completions for variables, functions. Apropos.
I’m starting work on a video series called for Speedrunning Emacs in the “I want to hack everything in Elisp” sense. Emacs is a programmable interface to a computer, so my interpretation is that using Emacs and using Elisp are inseparable.
https://www.youtube.com/watch?v=QU30EZiHNQw
It’s super new, so I’m recording right now and mainly covering things incidental to setting up casting for now and going over packages I’ve already published. Excited to get dug out of that hole and cover some of the things I want to.
Looks good. You have a good voice and speaking skills.
One recommendation is to cut the music out since people may prefer to listen to their own music in the background when watching videos or just not have any music at all.
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.
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.
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.
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
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
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.
Learn lisp :)
Just Use Vim
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
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
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”
