One of the oldest pieces of software still in use was recently described as

A sort of hybrid between Windows Notepad, a monolithic-kernel operating system, and the International Space Station.

Of course, they were talking about Emacs. And yes, it is kinda true.

I’ve been using Emacs for a while and had opportunities to use it to work on projects in remote machines. There are a few quirks, but after changing a setting here and there, Tramp is mostly usable. Tramp makes it possible to transparently treat remote directories, files, commands, and more, as if they were local. Opening a remote buffer via M-x find-file /ssh:user@remote-host:/some/project and having tools like Magit and Eshell work out of the box feels like magic.

I'm not aware of similar functionality in Vim, but VSCode users recently got something pretty close.

Emacs runs either as a standalone graphical application (GUI) or in a terminal emulator (TUI). In terms of features, GUI Emacs can be seen as a superset of TUI Emacs. Among many other things, it makes it possible to display:

  • images, PDFs, rendered web pages (even YouTube!)
  • graphical popups (with code documentation, linting tips, compilation errors, completion candidates, etc.)
  • heterogeneous fonts (distinct sizes, families, emphases, etc.)
TUI Emacs has the terminal emulator (and also commonly tmux) limiting and conflicting with the clipboard, keybindings, colors, and more. None of these limitations are present in GUI Emacs.

For these and other reasons I use GUI Emacs and Tramp to work on remote projects instead of TUI Emacs via SSH. Some do the opposite, and that’s fine too! Even with the limitations shown above, TUI Emacs is very powerful, and its performance in an SSH session is still superior to Tramp.

Even so, one might think displaying images in Emacs is not a big deal. Just open image.png and get an actual image viewer application to render it, right? Things get interesting in a remote Tramp buffer: M-x find-file image.png will display the remote image right there in your local Emacs instance. Or in case you’re in a remote dired buffer, pressing RET on an image file will do the same. It’s a non-disruptive workflow that allows one to remain in the comfort of Emacs.

dired is a built-in file manager.

If you’re not an Emacs user, chances are the previous sentence doesn’t carry much weight. What’s good about staying inside Emacs?

It is safe to assume that most of your development, or more broadly, your computing environment is represented below:

  • operating system (macOS, GNU/Linux distribution, Windows, etc.)
  • window manager (the one provided by your OS, i3, Openbox, XMonad, etc.)
  • terminal emulator (iTerm2, xterm, rxvt, alacritty, etc.)
  • shell (bash, zsh, fish, etc.)
  • terminal multiplexer (tmux, GNU Screen, etc.)
  • text editor or IDE (Vim, VSCode, Xcode, IntelliJ IDEA, etc.)
  • email, web browsing, multimedia, and communications

Each item above is a discrete computer program. They’re extensible in disconnected ways, and to varying degrees. They’re islands. Most of the time integrating them is an uphill battle, and commonly just plain impractical. Having used a computing environment centered around TUI Vim and tmux for a decade, I know the pain of trying to make the shell, the terminal, and every command line application running in it have the same look, feel, and behavior of being inside Vim. It is impossible.

The emergence of the web browser as a software platform is in part an answer to this disconnectedness.

In contrast, Emacs unifies and equalizes the computing experience as much as one desires, so that it happens—and is extended—in a single, cohesive environment.

Figure 2: My computing environment.

Figure 2: My computing environment.

People commonly use Emacs to process their email inbox, communicate in chat, navigate the web, write code, and prose. At their core, these activities are one and the same: text-editing. Being able to perform them using the same keybindings and functionality for movement, search, text manipulation, completion, undo-redo, copy-paste, is already a big deal, but it’s not all: their integration into a single environment unlocks pleasant and efficient workflows that would be much less convenient elsewhere.

Creating a to-do item for something your partner just asked you (while you were concentrated on a task) that will show up automatically on your agenda tomorrow? Just a few keystrokes and you’re back to the task. Converting some text notes you quickly scribbled down into a beautiful PDF via LaTeX, uploading it to S3, and referencing the URL in a reworded existing git commit message? If you’re an experienced Emacs user, chances are you can visualize effortlessly and efficiently executing these actions without ever leaving Emacs.

This interconnectedness is part of the value of computing environments like the one provided by Emacs. The whole becomes greater than the sum of its parts.

Programmability gives it a further dimension of value: parts can be combined as you see fit, in arbitrary and possibly unforeseen ways.

Now, back to the displaying an image from a remote host use case. For that, I can think of some alternatives:

  • scp the image file between hosts and open it locally
  • Mount the remote filesystem and open it locally
  • ssh into the remote host from a modern terminal emulator capable of rendering images and use a program like icat

In Emacs, you just press enter.