Emacs: an odyssey
I declare Dot Emacs Bankruptcy.
In this post, I share my odyssey into the world of Emacs.
Some History
Ever since I was introduced to Linux back in 2009, it has been a rabbit hole. Discovering, playing, and configuring the different tools to improve my workflow has been highly rewarding. One of the most used tools for me is an editor. This is how I came to adopt Emacs as my goto editor.
I started my Emacs journey back in 2015, roughly coinciding with the start of my Ph.D. Back then, I was looking for an application to take notes and maintain task lists. I started with Sublime text as my editor and markdown to take notes. I was very picky about having complete control of all my files. Hence I did not look at many cloud-based solutions that offer similar solutions. During that time was when I found org-mode. Sublime had a rudimentary package that handled org files, but it lacked too many features. And I enter the rabbit hole…Emacs.
The start was terrifying! The numerous shortcuts… the weird naming conventions…unfamiliar terminology… it felt a bit daunting. I found Spacemacs, a starter kit for Emacs. Back then, spacemacs was in its early stages too. Spacemacs provided vim like modal editing, so I used it for a couple of days as a text editor. When I was a bit more comfortable with the concept, I started building my own configuration.
The easiest way to start configuring Emacs is to copy other people’s configurations, and I did just that. A couple of talks that got me started were: Getting started with Org-mode and Evil Mode: or, How I Learned to Stop Worrying and Love Emacs. Soon enough, I had a decent configuration for using Emacs for tracking my tasks and writing. During this time, I also came across many amazing people and got an insight into how they were using Emacs, getting sucked deeper into the rabbit hole. Before I knew it, I was developing my workflow around Emacs.
Setting up my own configuration was a fantastic experience. I got to tailor my tools to precisely the way I wanted them to work. Of course, this took up a lot of time and effort. A few weeks back, I noticed my configuration had grown to about 3000 lines of code with a bunch of unused functions. As with all old code, I hardly remembered why I had it in the first place. Instead of cleaning up the configuration like I always did, I decided to switch to Doom Emacs. Doom Emacs as defined in their web page,
Doom is a configuration framework for GNU Emacs tailored for Emacs bankruptcy veterans who want less framework in their frameworks, a modicum of stability (and reproducibility) from their package manager, and the performance of a hand rolled config (or better). It can be a foundation for your own config or a resource for Emacs enthusiasts to learn more about our favorite operating system.
True to its word, I was able to set up Doom Emacs within a couple of hours to my liking based on my own configuration. My new personal configuration is barely 1000 lines and much more maintainable. It focuses only on the specific changes I want.
Migration to Doom
A few days ago, I spent some time migrating my vanilla Emacs configuration to Doom Emacs. The whole process took me about 3-5 hours, and then yesterday, I spent another hour or so tweaking the packages to work like I intend them to.
For reference, here is my original .emacs.d, and my current configuration here.
Why?
Maintaining my own config for the past few years took quite a bit of effort, and I could never get some settings to work. Most of the parts in my config are borrowed from someone or the other, and it is a big hotchpot of elisp code. They would either be minor conflicts between packages and each one overriding the other and also, as the configuration grew in size, there were many legacy bits in there I hardly used. While tinkering on a particular module, I looked at Dooms configuration for inspiration. So I decided to give Doom a try and really liked it.
Since both use similar package management styles, it was easy to port my own config into Doom.
But Doom offers more than a nice starting configuration. There’s a lot of machinery underneath that makes Doom Emacs fast. This was especially useful for me since I have had problems while updating packages on Emacs and in my host OS. Doom provides a sane way to update packages and also check for unsatisfied requirements. And, not to forget, the startup speed really impressed me.
The migration process
The Doom readme was decently documented, getting started wasn’t too hard. Installing Doom Emacs was a single line:
git clone https://github.com/hlissner/doom-emacs ~/.emacs.d
~/.emacs.d/bin/doom install
Doom uses evil-mode everywhere. The first step was to disable it. It took some time to figure out how Doom is structured. Once I understood that it was a breeze to configure. The in-built packages in Doom can be enabled/disabled in the init.el file. Packages that do not come built-in are to be defined in package.el.
The configuration lies in the config.el file. Since I prefer having a literate configuration, I choose to write it in config.org and then tangle it.
Final words
Migrating to Doom has increased the speed of my Emacs configuration, despite it behaving nearly the same. My configuration reduced from 3000+ lines to 1000 lines, containing the tweaks that truly make this Emacs configuration mine. My experience with Doom on Emacs keybindings has been good, and things work just like I expect them to (at least most of the time)!
Starting out with Emacs
Starting off with Emacs can be quite intimidating at first. The mistake most people make is to try to leverage every feature of Emacs from the start. They expect things to work similarly to fully functional IDEs from day 1. This expectation often leads them to leave Emacs.
Our tools must adapt to the way we(the user) work. These tools must essentially become an extension of ourselves and not the other way around. Understanding and internalizing this core philosophy takes some time for us who are accustomed to IDEs. Once internalized, it becomes a lot easier to work with and use Emacs more effectively. I briefly want to suggest my own strategy to learn and use Emacs for day-to-day activity.
Starting out with Vanilla Emacs can be daunting at first. There is a bunch of odd terminologies inherited from the ’70s that make it confusing to understand what people are saying. To add to this, the style of editing files in Emacs with all the different shortcuts is intimidating at first.
My advice for those starting out with Emacs for the first time: Since modal editing is much more intuitive, I would suggest starting out with something like Spacemacs or Doom Emacs. Start out by using Emacs for one or two use cases that suit your need. When I started, I used only org-mode to take my notes and maintain TODO lists. Once you grow comfortable and settle in, explore other features. Avoid learning more than two features at a given time during the first few weeks. After a few weeks of settling in, it is easier to start borrowing interesting configurations from other users and incorporating it into your workflow.
My Most Used Tools
Editor
Emacs has become my go-to editor. Built with the Unix philosophy it supports a ton of features and external tools that can easily be incorporated within the Emacs workflow. The most useful feature for me is its navigation. It is possible to quickly move around your document(s) with just a couple of keystrokes.
Searching and navigating through files with minimal keystrokes is what makes editing in Emacs great. There are tools/packages to search whole projects(projectile and grep).
Macros are my next favorite feature. When I need to do several repetitive changes in some text, it is easier to create a macro and get the task done. Sahas Subramanian has several tutorials on using Emacs through macros that highlight the power of macros for simple tasks.
Additionally I get to use these features across all my projects without learning to use new keybindings for different use cases. This includes writing in Latex, programming, maintaining personal finances, etc.
Org-mode
Org-mode is a major mode in Emacs that formats a document using the Org syntax. Org is a markup language similar to markdown, albeit much more powerful and simpler. It is merely a plaintext file and hence can be open, read, and modified is just any text editing tool. However, using it in org-mode provides a whole bunch of features. In this video Harry Schwartz walks through some of the features of org-mode.
In my workflow, I use org-mode to take notes and maintain todo lists. Broadly, I aim to make org-mode my second brain. More on that in another post hopefully.
Magit
Git is often the most used tool for me as a developer. It takes a lot of mental effort to using git, mainly on the command line. Magit provides an interface to the git command line. And it is just amazing. If not for anything, every developer must give Emacs a try just to experience the ease of Magit.
I don’t think exhaustive features of either org-mode or Magit can be communicated easily. Mike Zamansky has a video introducing Magit and if you are interested in more details John Wigley has a presentation about it. And, of-course there are many more videos and blogs documenting the use of Magit.
LSP
The LSP mode for emacs provides an IDE like interface for programming. LSP mode supports several different languages and is under heavy development. My primary choice of language is Scala. This language is supported by using Metals in the background. It helps me avoid heavy IDE tools like Eclipse and Intellij. Apparently, it is now possible to debug using DAP-mode. I have not tried it out yet, but seems to be worth checking out in the near future.
Mu4e
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
The above is Zawinski’s Law.
It is then safe to say that Emacs is here to stay. It has one of the best email handling package – Mu4e. Since I want to have all my files available offline and not linked to any specific vendor, this provides an excellent way to integrate all my email accounts.
Additionally, I can incorporate emails into my workflow much more effectively. For example, let’s say I get an email that requires some action. Using a particular combination of keystrokes, I will (automatically)add this action to my list of todo’s, along with the link to the email(on disk).
Let’s say the action was to write and send some documentation. In my org file under the todo item, I compose the documentation using org-mode syntax. Then by using some set of keystrokes, I can send everything under the TODO item as a reply to the sender, and Emacs (orgmode+mu4e) automatically formats the message to render correctly as HTML or plaintext.
Elfeed
Subscribing to blogs and other places on the internet was never so easy before. Elfeed is an RSS reader built for Emacs. Here maintain a list of all the interesting blogs and podcasts I subscribe to. I can then read these blogs from within my Emacs. Furthermore, if I find something very interesting saving it on my dist takes just one keystroke.
org-roam
One of the newer features I have been trying out. It tries to replace Roam Research, one of the new note-taking tools built upon the idea of Zettelkasten method. The note-taking idea is fascinating, and I hope to write about it in the near future. The org-roam package itself is relatively recent and has been under heavy development.
Notable people/resources
As mentioned, my whole journey was facilitated by learning from others. Here are some links to resources and people who I follow and have learned from.