Not Using Terminals, Part 2

In Part 1, we covered how terminals are not an entirely necessary part of an enjoyable computing experience. On the contrary, there are pretty good alternatives, especially if you are using Emacs.

We did not get especially far though. We did poke around in various directories and ran commands on files; this would be still pretty inconvenient though while e.g. iterating on a software project.

Compilation Mode

When writing code, one typically has two ways of compiling and running the code. One of them is some fancy IDE button with a green play triangle on it, which when pressed, compiles and runs the project in some predefined configuration. Usually, there are elaborate dialog boxes, with many fields specifying whether this is a debug configuration or a production one, or which command-line arguments to give to the freshly compiled program.

Sometimes this doesn't quite work. Maybe the project is too complex and the build system is too weird to fit into our IDE. Or what if all you want is to run a single Python file? Not worth the effort setting up all these tools for.

In these cases, people typically just revert to the standard tool: terminals. Namely, cd to the directory where the project files are, type a command, and keep pressing up arrow and Enter, combined by sifting through error messages by hand.

Of course, there are better alternatives.

Namely, Emacs has "compilation mode". It works similarly to running command line commands that we already discussed in part 1: you just run M-x compile (... or just C-x G or some other key combo), getting you a question about what command you want to run... then runs it, with the output going to a buffer. This is, so far, pretty similar to running commands asynchronously.

This being Emacs though, there's formatting and key bindings that make all of this a lot more interesting.

For example, let's say we have a Python script that we want to write, and try out occasionally in the process. We can just type the command that runs it; no need to cd anywhere since the current directory of the buffer we are editing is its location already.

We just hit Enter; we can see your results immediately.

You can jump on the line the error came from, just by clicking on it; just the way you would expect from a "proper" IDE.

The nice thing about this though is that it needs very little setup and it works on almost everything... for example, shell scripts.

You do not have to retype the command either. The next time you want to rerun your script or recompile your program you can just hit "g" in the compilation buffer.

Remote hosts

There is something mildly weird about the above screenshots. How exactly, after all, are we running bash scripts on Windows?

The thing is... we are not.

Emacs has functionality to pretend that remote buffers are local ones. It can operate via SSH, and it's pretty transparent. For example, if you open a file that looks like this:

/ssh:some_host.com:/home/user/

You get a directory browser in that directory on the remote host. Better yet, any command you run in this buffer will be executed remotely too.

E.g. here are the results from uname -a:

Which is exactly how compilation mode worked in the above examples.

(More than halfway?)

We still haven't gotten around the part about shell scripts... Nevertheless, we do have some more conclusions to draw in the meantime:

Emacs is not particularly better than other editors in especially many features. It is, however, really good at combining these things! Which then results in something really powerful.