What I Learned After My Short Trip to Emacs

So a few weeks ago, I had a wild idea to explore Emacs, after watching this hilarious clip from one of my favorite show Silicon Valley. For a long time, I have been curious what Emacs is, and why so many people claim it’s better than VIM (to be fair, there are also many people who claim Vim is better than Emacs), the only reason I did not try Emacs was just because I liked how easily it gets to move around and edit things in VIM, and I heard that Emacs doesn’t work that way. Luckily, after some research, I found out about Spacemacs, and later on, Doom-Emacs, both of which are built by ex-VIM users and have an Evil Mode, which provides VIM-like editing powers for Emacs. So I decided that it’s time to make that bold movement to Emacs, and, actually, was even looking forward to see how it goes. As I expected that by using Emacs, my productivity level would temporarily decrease, I made a promise to myself that no matter what happens, in at least two weeks, I won’t use any other editors but Emacs (and I did keep that promise).

After the two weeks, I liked Emacs quite a lot, so I continued working in it. While eventually, I did find myself coming back to VIM for several use-cases, I did learn quite a few things in Emacs, which made my workflow, even in VIM, much more convenient. In this article, I will jot down those things I think that Emacs rock, and also introduce some of their VIM’s equivalent replacements.

1. Magit

Magit is really something that makes you want to keep using Emacs forever. While Git is a great tool for version control, I always feel that the Git commandline is not always logical.

For example, using the Git CLI, there’s no straight-forward way that you can stage or unstage a file. For staging, you should use git add, while for unstaging, the command is git reset. While git add is not easily mistaken, git reset is a dangerous command, with three forms git reset --hard, --mixed and --soft, which make things quite complicated (I experience quite a few times of losing changes due to this complexity when I first encountered Git). Magit solves this problem by providing a command for staging and another for unstaging (I’ve always wondered why something like that was never an option for the Git CLI developers). And that is just an example of how powerful Magit is, in comparison with the Git CLI.

In Magit, you have an equivalent of git status, which shows every file that was changed and staged, changed but not staged, and not tracked on one screen. However, to explore what you have changed there, you can just press TAB. Almost everything on Magit is actionable, which means you can freely stage some lines in one command, and leave some lines for later commits, etc. And as I said earlier, not only that you can stage one file easily by pressing s, you can also unstage with u. Afterwards you can “c reate c ommit” (by pressing, as you might have guessed, cc), and even can push the changes to your remote repo using Magit.

The best part is: you don’t even have to leave Emacs to perform any of those commands, Magit runs natively on Emacs, and it offers very powerful tools to execute almost anything you can imagine on Git. So it’s fast and easy if you prefer working on one big window.

2. Org mode

I was really tempted to put Org-mode in the first of this list. Though in the end, I chose to move Magit above, I still feel very strongly that Org mode is something that you can find no where except in Emacs. It is a very convenient and powerful tool to organize your thoughts, and believe me, while your thoughts are the things you need to organize the most, doing it effectively is not easy. I have tried several things: concept maps, mind maps, diaries, notebooks, etc. Nothing works as effectively as org mode.

The basic idea of org-mode is a text file, in which every header is togglable (It is somewhat similar to VIM folding, but in many more levels and with text, not code). In it’s default, all-closed form, an org-mode document looks like a table of content, with only biggest headers visible, but you can extent the level of details in any header you like to explore more.

With org-mode, I was able to read a whole book, and you can do the same. It makes the absorption of ideas more naturally, as you can read the details about one small idea while also having a look at how it’s related to other things, and the possibility to explore another, related piece of information is possible.

Org-mode also has some other fun application, like writing your whole configuration file as if it is a human-readable documentation, what Distrotube does in this video.

3. Fuzzy Search

To be fair, I have known about Fuzzy search for a long time, and I installed CtrlP plugins in my VIM, like, years ago. However, I have never really used it: for one thing, I didn’t use buffers (since I normally open a new tab whenever I need to access another file), and CtrlP, by default, searches first on opening buffers. It’s also quite easy to just open a new terminal (especially if you have a Tiling window manager) and open a new VIM instance, so it had never occurred to me that fuzzy search and buffers are a much better way to deal with things.

Well, things changed when I moved to Emacs: tabs are no longer first class citizens, and you can’t find a tab line (or tab bar), as you normally find in VIM. At one point, I tried installing Centaur tabs on my Doom-Emacs, but then decided to remove, since it looks quite bad (I normally end up with two tab bars, since the extension rendered the tabs in header line, and enabled the native tab line at the same time). I was most influenced when I read the Reddit thread of this extension, in which some comments pointed out that you can’t rely on tabs, since you can only have a handful of them, while the number of files in your project should be much larger, and with fuzzy (file) searches and buffer list, you can access any file. So that’s what I decided to do, and it’s actually quite easy to do those things in Doom-Emacs. To open a fuzzy search for files in the same project, you just need to press <Space> ff, while the keystrokes for accessing a list of buffers is even shorter: <Space>,.

Doom-Emacs also takes into use Ag a fuzzy search command that works a bit like grep, but much faster. I find myself using it quite often, as sometimes I don’t remember the filename but some of its content.

Why did I move back to VIM then?

To be exact, I didn’t stop using Emacs (and don’t plan to do that at all, in fact, I am still writing this blog post in Emacs). What I did is just to come back to VIM in some use cases, while keep using Emacs for others. And here are the reasons:

1. VIM is lighter and faster

While Emacs provides several nice features, it does consume more resources than VIM. Though I haven’t made any specific measurement on how costly it is more than VIM, I did see Emacs have some serious hiccups when I opened a very large logs file (about 20k lines) with it, while VIM seems to have no problem opening the same file. (Here is a link of comparison between the two, in case you want some other opinions). As you know how I feel about minimalist software, I feel an urge of coming back to VIM every time I experienced even a slightly slowness.

2. VIM works on remote servers

Though Emacs has a terminal version, it looks quite ugly (in my POV), and doesn’t offer as much functionalities. The suggested way to use Emacs on a remote server is via TRAMP Mode, which is essentially a way of transferring files back and forth between your local and remote servers. I have never been a fan of this method, as it’s dependent on the Internet speed, so sometimes it’s quite slow (especially when your project is big). Running VIM directly on a SSH terminal is much faster (and less error-prone), because what you sent via Internet is just some keystrokes, which are read in by the VIM instance on your remote server.

3. Projects in VIM are more manageable

While it’s possible to open multiple Emacs instances, we won’t normally do that since it would be slow. To work on several projects in Emacs, the best way I found is to use Emacs Projectile, which globally stores a list of all projects that you have and allow you to isolate the actions (like fuzzy search) on per-project basis. While it’s nice in most cases, I find myself having to add new projects quite frequently, as sometimes the scope of the project turns out to be too big, or too small for the job I’m working on. On a very big project, what I normally end up having is a big project with everything, and several smaller projects, each consisting a sub-directory (or sub-sub-directory) of the big one. Needless to say, that’s quite messy.

In VIM, things are different: as you can just cd into any directory and open a VIM instance there, the need of managing things by global projects is not visible, hence no need for the extra step to add new projects.

4. I found some alternatives for what I need in VIM

I found out that several VIM users are also fond of those experience that Emacs users have, so many projects have been created with those aims in mind. Though it’s not always as good, by creating some shortcuts in my vim.rc, I was able to achieve, in VIM, almost everything I have loved in Emacs.

For Magit, I found this project: https://github.com/jreybert/vimagit that works for VIM. It seems that not every Magit command has been implemented, but for simple Git workflows like mine, it’s quite enough.

For Fuzzy Search, FZF VIM is a good VIM’s alternative. I find it easier to use than CtrlP, and it’s also extremely fast (maybe even faster than in Emacs). I had actually used the fzf(which is the backend package that does the fuzzy search magic) before, but it still feels much better to be able to perform it inside VIM (I even mapped <Space> ff to perform this search). I also use Buffergator to access list of opening buffers; having to type “:e” and then type in the full file name used to be my reason for not using buffers, now it’s gone.

Also related to fuzzy searching, I use Ag.vim to implement Ag search.

5. And finally, VIM is still better than Emacs’ Evil mode

Though Emacs evil-mode is very successful in making a VIM-like experience, every now and then, its behavior is still unpredictable for me. The difference is substance, but still noticeable. It’s not too much of an issue, though, but if I have to choose, I still like the native-VIM experience better than the Evil-mode’s.

Conclusion

At the end of the day, as you may have guessed, if I had to choose one of the two editors, I would choose VIM. Does it make me stop using Emacs? Not really. Emacs was the reason I learned to improve my VIM workflow, and Emacs, to me, still has so much potentials that I have not figured out yet.

And also, let’s not forget Org mode. It’s just unbeatable, you can’t get away from it once you know it.

So, why not both? What do you think?