Irreal

The other day I came across an old post by Vivek Haldar on what we want in an editor. I may have written about it before but it’s worth revisiting. He notes that for many people what they want includes “looks nice” but that’s crazy. “Good looking” for an editor means the font is readable, renders at a comfortable size, and the syntax highlighting makes sense. Anything else is irrelevant.

He makes a couple of other points worth mentioning. People often say that they have to use an editor for a while so they can adjust to it. Haldar says that’s backwards. Your editor should adjust to you, not the other way around.

Finally he says that editors are like fine wine: the older the better. If you want a good editor, choose one that’s been around long enough that all the quirks have been worked out and that every conceivable way of manipulating text has been considered and reified into workable code.

Tu Do (tuhdo) has an excellent series of primers on Emacs. The first one is the Emacs Mini Manual (PART 1) – THE BASICS. It’s about 40 pages when printed as a PDF so it’s much more than an extended cheat sheet. There are two more mini manuals covering Elisp and extending Emacs. There are also other articles on various Emacs subjects.

Part 1 of the mini manual is the best introduction to Emacs that I’ve seen. It covers everything you need to know to be an effective Emacs user. This includes topics like Dired, Macros, Registers, Ido, Version Control, and Shells as well as well as the usual navigation, search, and dealing with windows and frames subjects.

The mini manual reminds me of the Org Mode compact guide. It’s a shorter version of the complete Emacs manual optimized for getting up to speed as quickly as possible without drowning in all the details that the complete manual provides.

Even if you’re an experienced Emacs user, there’s probably a few details that will be new to you so it’s worth taking a look at it. I learned a couple of features about Dired that I didn’t know so it was very worthwhile for me.

At the end of the tutorial, tuhdo quotes a post, The Ghost in the Machine, by José Antonio Ortega Ruiz that captures my feelings about Emacs perfectly. He says that Emacs fills our yearning for a Lisp Machine. I’ve often written similar sentiments so I can relate. Those of us who try to do as much as possible in Emacs tend to think of it as a light weight Lisp Machine.

I haven’t read the rest of the manuals yet but I intend to. If they’re as good as Part 1, I’m sure to learn some new and useful things. If you’ve already read them, feel free to leave a comment.

Here’s a very nice tip from Johan Lindstrom:

#emacs tip: C-s (incremental-search), now C-w (pick up words), and then the real tip: M-% to query-replace the searched-for text. *BOOM*

— Johan Lindstrom (@jplindstrom) October 1, 2015

Artur Malabarba has an excellent Emacs tip on how to get the minibuffer to make an informed guess as to what who want to enter at the prompt. This is a really nice tip and something I didn’t know. Be sure to give it a read.

Daniel Gopar has started a series of Emacs interview podcasts called Emacs.el. His first subject, fittingly, is Sacha Chua. Gopar and Chua have a far ranging discussion on Emacs. Gopar starts off by asking the obligatory “How did you get started with Emacs?” question. As part of her response, Chua mentions how she leveraged Emacs Speak and ERC to tell her when someone mentions her on the IRC Emacs channel.

From there the discussion moved to how to learn Emacs. As we’ve all found out, that’s a never ending process and Chua says she learns things a little at time. I think it’s that way for most of us. We want to add something to our workflow or we see how someone else is doing things and we learn the bit of Emacs that makes that possible.

For me, the most interesting part of the interview was their discussion of Emacs Chats and Emacs Hangouts. Chua explains her rationale for the videos and how they differ. Many people will be surprised that Chua mentions her anxieties about the videos: that she won’t have a question to ask or that there will be awkward silences. She always seems so engaged and on top of things during the videos that it’s easy to miss the fact that, like most of us, she worries about her public performances.

It’s a nice chat. It lasts just shy of 42 minutes so you’ll have to schedule some time to watch it but it’s very worthwhile.

At Emacsconf 2015, Erik Hetzner gave a very interesting talk on Making Emacs a Better Tool for Scholars. Hetzner works for the Public Library of Science, which publishes about 30,000 papers every year. He notes that about 90% of those papers are submitted in Microsoft Word. Word is OK, he says, but not really a very good tools for scholars. In his quest to provide better tools he is looking at ways that Emacs can better meet scholars’ needs.

Hetzner makes an observation I hadn’t thought about before: the needs of scholars and programmers are remarkably similar. Where programmers talk about refactoring their code, scholars talk about revising/editing their papers but they are both concerned with adding, deleting, moving, and changing text.

There are more similarities. For example, scholars need to version control their papers. The publication cycle can be years long and perhaps changes specific to one or more journals will need to be made. Version control makes this easy as well as helping with collaboration.

An even less obvious similarity is the need to compile the results of the editing. In the case of scholars this may involve integrating citations; generating and adding graphs, figures, and charts; handling cross references; and dealing with one or more output format for the paper (HTML, PDF, ePub, etc.).

As Hetzner says, Org mode is Emacs’ secret weapon. Along with Babel, it gives researchers everything they need to do their calculations, graphs, and other processing right in the paper’s source file. Or, of course, to make reproducible research easy and natural. When it comes time to generate output, Org can generate a PDF, HTML, or, for those poor souls whose publishers require it, DOC.

The talk is a little over 30 and a half minutes so plan accordingly. You can see the slides from the talk on Hetzner’s Web site.

UPDATE: Fixed link to slides.