Dired and FTP

I maintain a Web site for our homeowners association. Mostly, this involves updating the monthly board meeting minutes, adding a pointer to them on the home page, and updating the minutes archive page. All of these pages, like this blog, are created in Emacs Org Mode and exported to HTML.

My normal procedure was to make the necessary changes to the .org files, export them to HTML, switch to a bash buffer, and call FTP at the command line to transfer the files to the hosting provider. I may or may not have remembered to clean up the HTML files and buffers when I finished. This was easy enough and only happened once a month so I never worried about whether there was a better way.

Recently, I was browsing around in Xah Lee's wonderful Emacs Tutorial and came across a page on using the shell in Emacs. On that page he mentions that you can FTP files directly from dired: just mark the files you want to transfer, press C (for copy) and when dired asks you for the destination type something like

/ftp:your-login-name@ftp-server-name:/your-directory

Thus I type something like

/ftp:jcs@hosting_service.com:/home-owners-association

Notice that second colon; you'll get a different result if you omit it.

The nice thing about this is that I'm still in the dired buffer with those files still marked so I can just type D to delete them and Emacs asks me if I want the associated buffers deleted too. I type y and all the files and buffers are cleaned up.

I'm sure I'm the last Emacs user on earth to discover all this but it's a nice way of doing that sort of thing. Anyone who does a lot a transferring of files between computers will find it a real time saver. You can use /scp: rather than /ftp: if the host you're transferring to supports it. Actually, Emacs supports several methods as described on this page of the Emacs manual.

Emacs 23.3 has been released.

Doubtless there are binaries available but I prefer to build my own. For Mac users, it's very easy to build right from the sources. First go to the Gnu Emacs Website and retrieve the tarball from Gnu.org or one of the mirrors. Untar it into a working directory and run

./configure --with-ns
make install

Then just move nextstep/Emacs.app to the applications folder. To be safe, you can rename your old emacs first so that you'll have a backup in case something went wrong with the build.

Emacs support for Scheme

Here's a nice summary of the various Emacs packages supporting Scheme from Alex Ott. The list includes general packages covering all Scheme implementations as well as packages specific to a single implementation, such as GDS for Guile and Xscheme for MIT Scheme.

Sadly, only Kawa and MIT Scheme have SLIME support.

Interview

Over at the essential emacs-fu, djcb has an interesting interview with Chong Yidong and Stefan Monnier, the current maintainers of Emacs. They talk about how they became maintainers, the Emacs 23.1 release, and their plans for the immediate future of Emacs 23. It's well worth a read.

Emacs 23 Released

The long awaited Emacs 23.1 was released yesterday as promised. I've been running the development version on a Mac for some time without any real problems, so there's no reason not to upgrade and give it a try.

Dragged kicking and screaming to Emacs (1)

I've been a staunch vi user for more than a quarter of a century, and although I never enlisted in the vi/Emacs holy wars, I was firm in my belief that vi—and especially its vim incarnation—was the right thing. I liked that it was lightweight and would start in an instant (although to be fair, that was less true of vim). I considered vi's modality—the main complaint of its detractors—a feature because it meant I didn't have to take my hands off the home row. It was fast and after all those years I was fast when I used it: all those cursor movement commands were burned into my muscle memory and I didn't have to think about them. It was almost as if vi were reading my mind.

Emacs, on the other hand, seemed bloated and clunky. Its huge memory footprint (neatly captured by the retronym Eventually Mallocs All of Core Storage) meant that it was painfully slow to start up. Its lack of modality meant that control sequences had to make extensive use of the metakeys giving rise to another retronym: Escape-Meta-Alt-Control-Shift. Its list of features, including a Towers of Hanoi puzzle seemed almost a caricature of marketing-driven featuritis.

Still, there were some things in Emacs that did invoke envy in the vi user. Its use of multiple windows meant that a user could edit related files (or different views of a single file) at the same time. Multiple buffers meant that a user could quickly switch between files without having to save the current file. Dired meant that a user could see the files in a directory and pick the right one to edit without having to fire up a separate shell and run ls. The built-in man command meant the user didn't have to leave the editor to make a quick check on the exact calling sequence of a function.

So every few years I'd make an attempt to adopt Emacs, but I was always overcome by minor annoyances: the jump scrolling seemed jarring; cursor control was physically painful; moving forward or backwards by words left the cursor in unexpected places; even the terminology seemed wrong (for example, yank means something else to the vi user). The result was always the same. I'd come home to vi but wish it had some of those neat Emacs features.

Finally, vim came along and provided most of the missing pieces that Emacs had but vi didn't. I was now completely content with vim and fully expected to stay with it until the heat death of the universe. But then something happened that changed everything.

—to be continued