The Emacs Way

Howard Abrams over at has a nice post on the The Tao of Emacs. His idea is to compare the Emacs workflow with that of other editors such as Vim. While Vim users have a shell-centric workflow where actions such as editing, compiling and testing are orchestrated from the shell, Emacs users prefer to stay in their editor and run the compilation and testing from there. Emacs, of course, has the tools to do this easily and “never leave Emacs” is a sacred precept for many Emacs users. Certainly almost all proficient Emacs users will perform the entire development cycle completely from with the editor.

Abrams then moves on to considering editing remote files. With Tramp, it's easy to retrieve a file on a remote server that's behind a firewall or even a set of firewalls. For frequently used files, this can be configured so that it happens automatically, but even a one-off edit is pretty easy because you can specify the series of hosts to go through in the file path. If you're using ssh keys, as you should, this will be almost transparent because you won't be prompted for passwords.

Abrams gives a nice example of something I hadn't thought about: you can make a call to sudo the last hop in the sequence of hosts in the file path. This allows you to edit file owned by root (or others) on the remote host. See Abrams post for the details. One final thing I didn't know is that you can bookmark a remote file and access it again very easily by simply invoking the bookmark. Again, see Abrams post for the details.

This is a nice post that makes explicit how the Emacs workflow differs from that of other editors. The bits about using Tramp may teach you things you didn't know. It's well worth a read.

UPDATE: Be sure to see Phil's comment about using sudo at the end of a chain of intermediate hosts.

This entry was posted in General and tagged . Bookmark the permalink.
  • Phil

    Please note that Abrams' example of using sudo in an ad-hoc multi-hop tramp path is incorrect. It seems to work fine, but it introduces a problem.

    See for details.

    Abrams has fallen into the same trap that you get by using sudo:: with remote hosts -- in this case the proxy host then becomes localhost, and so if you subsequently attempt to open /sudo:localhost:/path on your local server, you are proxied to the remote host from the prior multi-hop path.

    (or consider if you were using the sudo:localhost approach with more than one remote host -- you will clobber the proxy for root@localhost, and then one of those multi-hop paths will go to the wrong server!)

    You should always use the explicit remote hostname with the su and sudo methods, when multi-hopping.

    Abrams' example, when corrected, would be:

    • jcs

      Thanks for the tip--it's certainly not obvious. I've added a pointer to your comment in the post.