Emacs Everywhere

Updated 2017-10-17

This article was initially posted on Reddit. I’ve revised some arguments by taking the community feedback into account.

For many years I refrained from using Emacs everywhere because I clung to the following Unix philosophical principle: “Make each program do one thing well.” It did not make sense to me then to use a text editor as an e-mail client or a music library manager. I used to favour well-established ncurses programs like Mutt and cmus respectively.

When I started using Eshell as my main shell, the benefits of the Emacs interface became increasingly obvious. Maybe my initial reasoning was not well founded after all. Since then I successfully moved on to using this user-interface-on-steroids everywhere. Looking back, it feels like I had been missing out and wasted my time for that many years.

This realization is what leads me to write a pamphlet on the matter to help the user community move forward out of a loop of misconception that does not help but waste everybody’s time. I hope to help informing you with strong arguments as to why you should or you should not use Emacs extensively.

Too often the same fallacious misconceptions stir endless debates:

Configuring Emacs cost thousands of hours just to tweak the editor, so sending e-mails with Emacs is simply not within my reach.

or, even more famously

Emacs is a great operating system, lacking only a decent editor.

While obviously sarcastic, it might be worth point out that no, Emacs’ intent is not to be an operating system. That being said, it is true that Emacs is not only an editor. From a broader perspective, it would be best described as a programmable, text-oriented user-interface (containing, among others, an editor).

As such it is erroneous to discard Emacs special modes for the sole reason that an editor should not do anything but editing text. If you think of Emacs as a user interface, then it covers the same ground as Qt, GTK, Tk or curses and the Unix-philosophical argument falls flat.

As a matter of fact, using Emacs to send e-mails or listen to music is usually much simpler than configuring the editor. This is because an editor is intrisically richer in terms of features and configuration possibilities.

Emacs might not suit everybody’s needs everywhere, although I believe that more often than not it will. Hopefully the insights of this pamphlet will add enough fuel to the fire to help nuance the various views held by the community.

Emacs vs. the others

The power features Emacs offers and that are lacking in other “common” interfaces (GTK, Qt, Tk, EFL, cocoa, curses, etc.) include:

What Emacs really does

Now let’s move on to the core of the question: Is it wise to have everything run from within Emacs?

A common misconception when thinking of “Emacs as an OS” is to assume that Emacs special modes are re-inventing the wheel. They are not (for most of them), Emacs and its modes focus on the user interface side of things. The backends are almost always separate programs. This is precisely where the Unix philosophy still stands strong. Using Emacs as an interface for everything is merely equivalent to using GTK-only applications. (Only much better, obviously.)

As opposed to other user interfaces Emacs is a programmable environment: any structure, interface element and even code can be passed around and combined between the different interfaces to various programs. Consider those canonical features:

All of them can be applied to (when it makes sense):

And many more.

Emacs does not lure developers into reinventing the wheel, quite the opposite: it shines at reusing and combining features in the most unexpected ways.

The perks of Emacs as a user interface

There is more to it:

Side effects and other niceties

EXWM to rule them all

Warning: Aficionados of sparkles and glitter, behold! EXWM is visually as barren as Emacs gets!

EXWM was for me the last milestone in the course of The Big Shift to a fully Emacs-based environment.

I’ve been an avid user of AwesomeWM for years, but with time I grew tired of “losing windows” among the excess of workspaces (tags in Awesome terminology) or screens. I wish I could have just fuzzy-searched them with fzf or something similar. I never managed to implement the idea. Until I discovered EXWM.

EXWM has all the benefits of being Emacs-based with the particularity that all X windows are buffers and as such are part of Emacs buffer list, which makes for the capability to fuzzy-select windows with Helm or Ivy! “Lost windows” belong to the past. When opening several windows at once, you can configure how to display them. (This is a recent addition to Helm.) A nice use-case is to first narrow down some windows using Helm patterns, display them all in an “Exposé” fashion, and finally select your desired windows visually.

Concretely, I have the following bindings:

The “Exposé” binding sequence:

s-b <filter> M-a RET
s-<hjkl> RET

Say I have a few Wikipedia pages of which I want to want to select one which title I do not remember:

s-b wikipedia M-a RET

Or usually it’s enough with

s-b wk M-a RET

then

s-l s-j RET

if if’s the second window to the right then down.

Since the window management is extensible, you can write your own helm-window-show-buffers-function to fine-tune your needs:

It is so convenient to lookup buffers with EXWM+Helm that I’ve quit using workspaces (a.k.a. tags) altogether in favour of a more global approach.

Maybe one the most noticeable benefit on a daily basis is that it lifts up some weight off the cognitive burden of having to manage windows both from Emacs and from an external window manager. With EXWM, there is no more need to remember two sets of bindings and windowing rules, the windowing being effectively fully centralized. For instance I used to reserve the super key for all windowing bindings with AwesomeWM; now I reserve it to all Emacs windowing operations, and there is no need for other bindings.

Adepts of the suckless philosophy would argue that Emacs should leave all windowing, including its own, to an external specialized program, the window manager. But from the perspective that Emacs is a user interface, it is not that much of a heresy to consider that Emacs is precisely that window manager.

Having Emacs as a window manager has some additional benefits, namely that it is fully aware of the content of the Emacs buffer, which allows for specializing windowing actions depending of the different buffers. This is much harder to do with any other window manager.

Examples and list of programs