Emacs Everywhere

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: Everything is text, everything is searchable and copy-able. Even better, you can fuzzy-search anything. Enter Helm, Ivy and others.

It can be fully keyboard-controlled (not very common with GTK and friends), while mouse controls are supported too (which sucks in ncurses).

It works both in graphical and textual environments, mostly out-of-the-box. Nevertheless you should prefer the less limited graphical Emacs: all keyboard modifiers are supported, various font sizes can be displayed, and… pictures!

Configuration is done in Emacs Lisp. Which is the best language ever, as we all know. At least when it comes to extensibility. And even if you don’t agree with that, it sucks less than most of its competitors.

Configuration, as a consequence of being Lisp, can be tracked by version control systems.

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: Buffers

The kill-ring

The “undo” command (or better: undo-tree)

Macros

Bookmarks

Windows

Abbreviations if that’s your thing

Snippets if that’s your thing

Completion

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

Gnus, mu4e, whatever e-mail client you prefer

Dired, Helm-find-files

Elfeed, Gnus again

EMMS

Org-mode (notes, agenda, contacts, publishing…) 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: Since Emacs can display pictures: EMMS can display album covers, e-mails can display inline attachments.

Configuration consistency: Bindings, color themes and other interface elements are consistently shared across the various special modes. No need to waste time syncing the different configuration files of your different programs (in different configuration languages).

(in different configuration languages). Configure, extend, fix: With Emacs, everything is configurable, even what was not foreseen by its developers. All the Lisp source code is available at hand. Want to add a feature? It’s usually as simple as adding a few Elisp lines to the configuration. Something is broken? After reporting it upstream, you don’t have to wait for the next release, you can hot-patch the bug from your configuration.

Universality. Emacs is somewhat easy to compile. It runs on virtually all desktop platforms you could think of. As such, running everything from Emacs effectively abstracts away the OS user interface, which makes it possible to use your personal configuration on any system. This is especially useful when you are forced to a famous crappy OS.

OS-independent package manager: This provides the user with cutting-edge packages even on (rusty) conservative distributions or when the user has no privileges.

Flatter learning-curve for new programs: Emacs documentation system is (more or less) consistently used among all Emacs modes, which makes the learning process of a new mode somewhat easier. No need to figure out where the static documentation is (HTML page? man page?), Emacs lets you (fuzzy-)search the configuration variables and the bindings.

Lightweight, efficient: When I replaced all my super-lightweight curses programs with their Emacs counterparts, I did not notice a significant change in disk usage. With the difference that ELPA packages have both the source code and the byte-compiled files installed. For programmers and tinkerers, having source code at hand is a boon. In terms of performance, graphical Emacs is not limited by the restrictions born by terminal emulators and inflicted upon curses programs.

Side effects and other niceties Another perk of using Emacs as everything is the ubiquitous global state of all Emacs special modes. Say you want to switch transmission to turtle mode, there is no need to switch to transmission first, you can invoke the command or its associated binding directly, regardless of the buffers curretly under focus. Same goes for music with EMMS, or anything else running in the background.

of all Emacs special modes. Say you want to switch transmission to turtle mode, there is no need to switch to transmission first, you can invoke the command or its associated binding directly, regardless of the buffers curretly under focus. Same goes for music with EMMS, or anything else running in the background. If you use Eshell, you don’t need that lengthy, clunky bash/zsh/fish configuration anymore.

Other cumbersome configurations can go: dircolors , lesspipe , Xresources … Even fzf can be disposed of.

, , … Even can be disposed of. No need to duplicate your dotfiles for the root user or on remote machines: use TRAMP!

“Apps” for web services: debbugs (to browse the Emacs bug tracker), mediawiki-mode to browse and edit MediaWiki-based pages, sx to work with StackExchange pages…

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: s-b : helm-mini

: M-a : helm-mark-all

: s-<hjkl> : windmove-* 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: Always display the compile buffer at the same spot with a specific height.

If all buffers are web browser windows, pop them up in a mosaic tiling. If not, use a master-slave tiling.

Behave differently depending on the number of buffers or depending on the content or the modes.

Keep a column of “tools” to the right (calendar, calculator, etc.). 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.